在哪些情况下使用工厂类而不是静态函数是有意义的？

Question

目前我已经创建了一个ABCFactory类，它有一个创建ABC对象的方法。现在我想起来了，也许不是有工厂，我可以在我的ABC方法中制作一个静态方法。进行此项更改的专业人士和合作伙伴是什么？它不会导致相同吗？我不预见其他类会继承ABC，但是一个人永远都不知道！

由于

Answer 1

使用单个静态方法会使测试变得更加困难，而拥有可实例化的对象可以使其更容易测试。此外，依赖注入后来更多地是非静态解决方案的选项。

当然，如果你不需要这些，那么这些都不是好的论据。

Answer 2

工厂方法的主要优点是能够隐藏对接口后面的特定类的引用。由于静态方法不能作为接口的一部分，因此静态工厂方法与构造方法本身基本相同。静态工厂方法唯一有用的应用是提供对私有构造函数的访问 - 通常用于单例模式实现。

Answer 3

实际上，如果你想获得工厂类的好处，你需要在它自己的类中使用静态方法。这将允许您稍后创建新的工厂类，或重新配置现有的类以获得不同的行为。例如，一个工厂类可能会创建实现IFourHoovedAnimal接口的Unicorns。您可能编写了一个使用IFourHoovedAnimal执行操作并且需要实例化它们的算法。稍后您可以创建一个新的工厂类，而不是实例化Pegasus，它也实现了IFourHoovedAnimal。现在可以通过使用新工厂将旧算法重用于Pegasus！为了使这项工作，PegasusFactory和UnicornFactory必须从一些常见的基类（通常是一个抽象类）继承。

因此，通过将静态方法放在其自己的工厂类中，您可以将工厂类与较新的工厂类交换，以重用旧算法。这也有助于提高可测试性，因为现在可以为创建模拟对象的工厂提供单元测试。

我之前已经为非常小的项目完成了后者（你正在创建实例的类上的静态工厂方法），但这只是因为我需要它来帮助重构一些旧代码，但是将更改保持在最低限度。基本上在这种情况下，我已经考虑了一大堆代码，这些代码创建了一堆ASP.NET控件，并将所有这些控件填充到用户控件中。我想基于新的用户控件属性，但旧的遗留代码更容易使用基于参数的构造函数创建用户控件。

所以我创建了一个采用所有参数的静态工厂方法，然后实例化用户控件并根据参数设置它的属性。旧的遗留代码使用此静态方法来创建用户控件，而未来的代码将使用“更漂亮”的属性。

Answer 4

对于具体的类，工厂方法实际上只是一种创建实际类型的间接方法（这并不是说它们没用，但正如你所发现的那样，工厂方法可能真的是任何地方）。

工厂方法真正发光的地方是你的方法创建接口类型的实例。

Answer 5

Uncle Bob's SOLID Principles of Object Oriented Design中的“D”是“依赖性倒置原则”取决于抽象而非结果。

该原则的极端追随可能会让您的主类创建所有工厂，每个工厂通过接口使用其他工厂。 “new”（创建具体对象）的唯一外观将出现在您的主类和您的工厂中。所有对象都可以使用接口（抽象），具体依赖于从提供的工厂实现中获得。

然后，您可以非常轻松地调整，或提供针对不同场景定制的多个主要类。

Answer 6

过度使用设计模式是危险的，当您具有已定义接口的类层次结构或需要构建相当复杂的对象时，创建设计模式才有意义。如果您的设计简单，请使用简单的解决方案。因此，在您的情况下，工厂方法就足够了

是的，你是对的，这是另一种设计模式:)