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

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

谢谢

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

因此,您可以通过将静态方法放在其自己的工厂类中来看到,您可以将工厂类换成更新的工厂类以重用旧算法。 这也有助于提高可测试性,因为现在可以为创建模拟对象的工厂提供unit testing。

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

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

使用单个静态方法会使测试更加困难,而拥有可实例化的对象可以使测试更容易。 此外,dependency injection后来更多地是非静态解决方案的选项。

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

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

对于具体的类,工厂方法实际上只是一种围绕创建实际类型的间接方法(这并不是说它们没用,但正如你所发现的那样,工厂方法实际上可以在任何地方 )。

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

鲍勃叔叔的面向对象设计的SOLID原则中的“D”是“依赖倒置原则” 取决于抽象,而不是结构。

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

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

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

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