保留整个对象VS不要寻找东西 [英] Preserve Whole Object VS Don't Look For Things
问题描述
我正在阅读Fowler的重构书，看到了保留整个对象.另一种不同的新观点认为，这种重构与您应该执行的操作完全相反:干净代码讨论" -不要找东西！.
I was reading Fowler's Refactoring Book and saw Preserve Whole Object. A different, newer opinion says that this refactoring is the exact opposite of what you should do: The Clean Code Talks - Don't Look For Things!.
Fowler确实提到您应该查看该方法是否可以仅移至使用大量参数的类.我认为这将是唯一合理的选择.对于一个定义不明确的方法，这种重构似乎是一个创可贴.
Fowler does mention that you should look to see if the method can just be moved to the class which uses the large list of arguments. I think that would be the only reasonable alternative. This refactoring seems like a band-aid for a poorly defined method.
Fowler的原始资料有些陈旧.是让这种技术沿dodo方式流行的主流智慧，还是实际上确实存在您想要进行这种重构的情况?还是我误解了测试驱动风格，因为这些示例涉及对象构造而不是消息发送?
The Fowler source material is a bit dated. Is the prevailing wisdom to let this technique go the way of the dodo or is there actually a case when you'd want to do this kind of refactoring? Or have I misunderstood the test-driven style because those examples deal with object construction, not message sending?
推荐答案
面向对象设计中有很多概念，例如模式，原理和实践，乍一看似乎很相似或矛盾.实际上，它们中的大多数既不相似也不矛盾.使他们与众不同和一致的是他们的意图.
There are many concepts in the Object Oriented Design such as Patterns, Principles and Practices that may seem to be either similar or contradictory at first. In fact, most of them are neither similar nor contradictory. And the thing that makes them different and consistent is their intent.
干净代码对话"视频中提到的保留整个对象重构和服务定位器模式之间看似矛盾的情况发生在它们被视为相同概念时，尽管它们在意图和本质上是不同的.
The seeming contradiction between the Preserve Whole Object refactoring and the Service Locator pattern mentioned in The Clean Code Talks video occurs when they are treated as a same concept, although they are different in their intent and their essence.
保留整个对象重构只是一种用于通过减少函数的参数数量来使代码更易于阅读，理解和维护的技术.另一方面，服务定位器是一种设计模式，用于使用控制反转概念管理系统中不同组件之间的依赖关系. 保留整个对象重构技术对系统具有局部影响，该技术应用于系统的一小部分(功能)，而 Service Locator 模式具有一个对系统的全局影响，并解决了更大的体系结构问题(依赖管理).
The Preserve Whole Object refactoring is simply a technique used to make code easier to read, understand and maintain by reducing the number of arguments to a function. The Service Locator, on the other hand, is a design pattern that is used to manage dependencies between different components in a system using the Inversion of Control concept. Unlike the Preserve Whole Object refactoring technique which has local effect on a system, that is applied to a small part of the system (a function), the Service Locator pattern has a global effect on the system and addresses a bigger architectural problem (Dependency Management).
当函数有两个或多个参数(基本上是一个对象的属性)时，请使用保留整个对象重构.
Use the Preserve Whole Object refactoring when You have two or more arguments to a function which are basically the properties of one object, so pass the object instead.
有一个类似的概念，称为 Parameter Object (又名 Argument Object )(
There is a similar concept called Parameter Object (aka Argument Object) (Introduce Parameter Object refactoring) which states that if You have a group of parameters that are not the properties of one object but are conceptually related to each other or naturally go together, wrap them with a class of their own and pass the instance of that class instead. It is mainly used when sending a message to an object.
清洁代码中的引言，第3章，函数，函数参数，第43页(Robert C. Martin):
A quote from Clean Code, Chapter 3: Functions, Function Arguments, page 43 (Robert C. Martin):
自变量对象
当一个函数似乎需要两个或三个以上的参数时，可能其中一些 这些论点应该包装成自己的一类.例如，考虑 以下两个声明之间的区别:
When a function seems to need more than two or three arguments, it is likely that some of those arguments ought to be wrapped into a class of their own. Consider, for example, the difference between the two following declarations:
Circle makeCircle(double x, double y, double radius);
Circle makeCircle(Point center, double radius);
通过在其中创建对象来减少参数的数量可能看起来像 作弊，但事实并非如此.当变量组一起传递时，x和x的方式 y在上面的示例中，它们很可能是应得其名的概念的一部分 自己的.
Reducing the number of arguments by creating objects out of them may seem like cheating, but it’s not. When groups of variables are passed together, the way x and y are in the example above, they are likely part of a concept that deserves a name of its own.
何时使用服务定位器模式?
当您的类具有在概念上不相关的依赖项并且您不希望您的类依赖于具体的实现时，请使用服务定位器模式.实际上，这是您要使用任何 Dependency Management 方法的时候.另一种选择是 Dependency Injection 方法，该方法将所有依赖项显式指定为构造函数的单独参数.而服务定位器将所有依赖项传递到单个容器对象中.实际上，正是在 Service Locator 模式和 Preserve Whole Object 重构之间非常相似，这种重构将参数合并到单个对象中，这引起了混乱. Dependency Management 技术主要用于对象构造.
When to use the Service Locator pattern?
Use the Service Locator pattern when Your class has dependencies that are not conceptually related and You do not want Your class to depend on concrete implementations. Actually, this is when You would want to use any of the Dependency Management approaches. Another alternative is the Dependency Injection approach which explicitly specifies all the dependencies as a separate arguments to the constructor. Whereas the Service Locator pass all the dependencies in a single container object. In fact, it is this very similarity between the Service Locator pattern and the Preserve Whole Object refactoring of combining the arguments in a single object that serves as a source of confusion. The Dependency Management techniques are mainly used in object construction.
There are pros and cons to both approaches of the Dependency Management which are discussed in the Inversion of Control Containers and the Dependency Injection pattern article by Martin Fowler.
有时候，您的类将具有两个或多个在概念上相关的依赖项，您可能希望将它们组合在一个对象中，并使用 Service Locator 作为依赖项传递.因此，如您所见，这两个概念并不互斥.
Sometimes there will be situations where Your class will have two or more dependencies that are conceptually related and You might want to combine them in a single object and pass it as a dependency using the Service Locator. So, as You can see these two concepts are not mutually exclusive.
这篇关于保留整个对象VS不要寻找东西的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
