在整个系统中创建具有相同参数的对象答案

【问题标题】：Creating objects with the same arguments across the system在整个系统中创建具有相同参数的对象
【发布时间】：2012-12-15 19:51:32
【问题描述】：

我有一个执行非常具体的任务的对象。要创建此对象，需要一些参数。我在系统的某些部分创建了一个新实例。但是有问题。如果将来必须更改参数或参数怎么办？我需要在任何地方进行更改。然后我想：“好吧，也许我可以将它的创建封装在一个类中，如果某些参数发生变化，我只需要在一个地方进行更改！”。

这对我来说确实很有意义。真正的问题是，这个“包装”对象是工厂吗？它的职责是“创建一个具有特定参数的新对象并返回它”。消费者只会使用这个对象...

【问题讨论】：

我想这将是一个（非常简单的）工厂。您是否有机会在外部指定参数，并让工厂读取它们并相应地实例化？如果是这样，您也许可以允许修改行为而根本不更改代码（以可能难以阅读/理解的配置为代价）。
实际上它是一个单独的类，每次都用相同的参数实例化......

【解决方案1】：

您重构代码以避免重复，这本身可能会提高您的整体可维护性。

如果这段重构代码正在创建对象，那么，是的，它是一个工厂。你怎么称呼它真的没关系 - 现在你的代码结构更好了吗？那就去做吧！

但是，鉴于它是工厂，请研究有关工厂的经典设计模式，并了解是什么导致人们使用这种模式的更复杂形式。决定你是否有任何力量导致他们使用“聪明”的工厂。

【讨论】：

【解决方案2】：

您描述的问题是，当该类的构造函数参数更改时，您的类的所有客户端都必须更改。引入工厂可以帮助防止重新编译客户端。但这真的能解决问题吗？如果您修改要使用另一个参数构造的类，则必须在某处确定该参数，可能在启动构造的客户端的上下文中。工厂类应该怎么知道？客户是否必须将任何上下文信息传递给工厂？

构造对象需要哪些参数？客户是否提供了它们，或者是否可以事先创建对象，然后像注入工厂一样将其注入客户端（据我了解，您的问题似乎是这种情况）？考虑使用DI framework。这通常会使工厂过时。

你为什么害怕你的班级可能被改变？会不会是你的课做的太多了？请注意Single Responsibility Principle。在您的情况下，Open/Closed Principle 也是一项有趣的研究。

据我了解，工厂不一定能解决您描述的问题。工厂负责创建远离客户端的对象，因此客户端不必知道对象的具体类型。也可以通过将参数包装在单个对象中来防止签名保持稳定。这也是众所周知的refactoring pattern。但这也没有解决新参数从何而来的问题。

【讨论】：