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

目前我创建了一个ABCFactory类，它有一个创建ABC对象的方法。现在我想到了，也许没有工厂，我可以在我的ABC方法中创建一个静态方法。什么是专业人士和骗子在做这个改变？它会不会导致相同的？我没有预见到其他类会继承ABC，但从来不知道！在哪些情况下，使用工厂类而不是静态函数是有意义的？

感谢

来源

2010-04-01 devoured elysium

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

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

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

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

来源

2010-04-01 21:12:56 AaronLS

对于具体的类，工厂方法实际上只是一个间接围绕创建实际的类型（这并不是说他们是没有用的方法，但你发现，工厂方法真的可以在任何地方）。

工厂方法真正发光的地方在于您的方法创建接口类型的实例。

来源

2010-04-01 21:06:42

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

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

来源

2010-04-01 21:06:57 Jaxidian

为什么更容易测试与非静态方法？ – 2010-04-01 21:12:26

@devoured elysium：例如，一个测试类可能包含原始的一个子类，这个子类覆盖了该方法，用于仪器或正常行为的短路。这不是（很容易）使用静态方法。 – 2010-04-01 21:34:49

@devoured elysium - 因为你不能将静态类作为参数传递给测试方法（至少不是很好）。这与关于依赖注入的第二点有关。但是，正如加西迪安所说，这些点可能并不重要。 – 2010-04-01 21:37:41

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

来源

2010-04-01 21:29:41 newtover

+1简洁明了。 – 2010-04-01 21:39:47

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

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

您可以很容易地调整，或提供多个为不同场景定制的主类。

来源

2010-04-01 22:14:06

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

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

来源

2010-04-02 07:20:09

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

回答

相关问题