保留整个物体VS不要寻找东西

Question

我正在阅读福勒的重构书,并看到了保留整个对象.一个不同的,更新的观点说,这种重构与你应该做的完全相反:清洁代码会谈 - 不要寻找东西!.

Fowler确实提到过,您应该查看该方法是否可以移动到使用大型参数列表的类.我认为这将是唯一合理的选择.这种重构看起来像是一种定义不明确的方法的创可贴.

福勒的源材料有点陈旧.流行的智慧是让这种技术成为渡渡鸟的方式,还是在你想要进行这种重构的时候？或者我误解了测试驱动的风格,因为这些例子涉及对象构造,而不是消息发送？

Answer 1

面向对象设计中有许多概念,例如模式,原则和实践,起初可能看起来相似或相互矛盾.事实上,他们中的大多数既不相似也不矛盾.而使他们与众不同且一致的事情就是他们的意图.

" 清洁代码谈判"视频中提到的保留整个对象重构和服务定位器模式之间的看似矛盾发生在它们被视为相同的概念时,尽管它们的意图和本质不同.

该保护区中的整体重构仅仅是用来使代码更易于阅读,理解并通过减少参数个数的功能维持的技术.的服务定位器,在另一方面,是用于管理在使用的系统的不同组件之间的相关性的设计图案反转控制的概念.与对系统具有局部影响的Preserve Whole Object重构技术(应用于系统的一小部分(函数))不同,Service Locator模式对系统具有全局影响并解决更大的架构问题(依赖关系管理)).

何时使用Preserve Whole Object重构？

当您有一个函数的两个或多个参数(基本上是一个对象的属性)时,请使用" 保留整个对象"重构,因此请传递该对象.

有一个类似的概念叫做参数对象(又名参数对象)(介绍参数对象重构),它说明如果你有一组参数不是一个对象的属性但是在概念上彼此相关或者自然地在一起,那么换行他们使用自己的类,然后传递该类的实例.它主要用于向对象发送消息时使用.

清洁代码引用,第3章:函数,函数参数,第43页(Robert C. Martin):

参数对象

当一个函数似乎需要两个或三个以上的参数时,很可能这些参数中的一些应该被包装成它们自己的类.例如,考虑以下两个声明之间的区别:

Circle makeCircle(double x, double y, double radius);
Circle makeCircle(Point center, double radius);

通过从中创建对象来减少参数的数量可能看起来像是作弊,但事实并非如此.当变量组一起传递时,x和y的方式在上面的例子中,它们可能是一个值得拥有自己名字的概念的一部分.

何时使用服务定位器模式？

当您的类具有非概念相关的依赖项并且您不希望您的类依赖于具体实现时,请使用服务定位器模式.实际上,这是您希望使用任何依赖关系管理方法的时候.另一种替代方法是依赖注入方法,它明确地将所有依赖项指定为构造函数的单独参数.而服务定位器将所有依赖项传递到单个容器对象中.实际上,服务定位器模式与保留整个对象重构之间的这种非常相似,即将单个对象中的参数组合起来作为混淆源.该依赖管理技术主要应用于对象的构造.

依赖管理的两种方法都有利有弊,这些方法在控制容器的反转和 Martin Fowler 的依赖注入模式文章中讨论过.

何时使用？

有时会出现这样的情况,即您的类将具有两个或多个概念相关的依赖项,您可能希望将它们组合在一个对象中,并使用服务定位器将其作为依赖项传递.所以,正如你可以看到这两个概念并不相互排斥.