我有一个执行特定任务的对象。要创建，此对象需要一些参数。我在系统的某些部分创建了一个新实例。但是有问题。如果将来必须更改参数或参数怎么办？我需要在任何地方改变它。然后我想：“好吧，也许我可以将它的创作封装在一个类中，如果一些参数改变了，我将需要在一个地方改变它！”。
这对我来说确实很有意义。真正的问题是，这个“包装”对象是工厂吗？它的职责是“使用特定参数创建一个新对象并将其返回”。消费者只会使用这个对象......
答案 0 :(得分：0)
您需要重构代码以避免重复，这本身可能会提高您的整体可维护性。
如果这条重构代码正在创建对象，那么，是的，它是一个工厂。你称它为什么并不重要 - 现在你的代码是更好的结构吗？然后去做！
然而，鉴于这是一项工厂研究，有关工厂的经典设计模式，并了解是什么导致人们使用这种模式的更复杂形式。决定你是否有任何力量导致他们使用“聪明”的工厂。
答案 1 :(得分：0)
您描述的问题是，当该类的构造函数参数发生更改时，您的类的所有客户端都必须更改。引入工厂可以帮助防止重新编译客户端。但这真的解决了这个问题吗？如果修改要使用另一个参数构造的类，则必须在某处确定参数，可能在启动构造的客户端的上下文中。工厂班应该怎么知道？客户是否必须将任何上下文信息传递给工厂？
构建对象需要哪些参数？客户是否提供它们或者可以预先创建对象，然后注入工厂（因为我理解你的问题，后者似乎是这种情况）？考虑使用DI framework。这通常会使工厂过时。
为什么你害怕你的班级可能被改变？可能是你的班级做得太多了吗？记住Single Responsibility Principle。在你的情况下，Open/Closed Principle也是一项有趣的研究。
据我所知，工厂不一定能解决您描述的问题。工厂负责远离客户创建对象，因此客户端不必知道对象的具体类型。仅通过将参数包装在单个对象中也可以防止签名保持稳定。这也是一个众所周知的refactoring pattern。但它也没有解决新参数来自何处的问题。