5

目前我已经创建了一个 ABCFactory 类，它有一个创建 ABC 对象的方法。现在我想起来了，也许我可以在我的 ABC 方法中创建一个静态方法，而不是拥有一个工厂。进行此更改的利弊是什么？它不会导致同样的结果吗？我不预见其他类会继承 ABC，但永远不知道！

谢谢

4

6 回答 6

4

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

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

于 2010-04-01T21:06:57.133 回答
3

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

于 2010-04-01T21:29:41.297 回答
2

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

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

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

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

于 2010-04-01T21:12:56.443 回答
1

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

工厂方法真正闪耀的地方是当您的方法创建接口类型的实例时。

于 2010-04-01T21:06:42.790 回答
1

Bob叔叔的面向对象设计的SOLID原则中的“D”是“依赖倒置原则”依赖于抽象，而不是具体化。

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

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

于 2010-04-01T22:14:06.273 回答
1

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

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

于 2010-04-02T07:20:09.117 回答