敏捷软件开发 – FACTORY模式

　　依赖倒置原则（DIP）告诉我们应该优先依赖于抽象类，而避免依赖于具体类。当这些具体类不稳定时，更应该如此。因此，下面的代码片段违反了这条原则：

Circle c = new Circle(origin, 1);

　　Circle是一个具体类。所以，创建Circle类实例的模块肯定违反了DIP。事实上，任何一行使用了new关键字的代码都违反了DIP。

　　有时，违反DIP是无害的。一个具体类约有可能改变，依赖于它就越有可能引发问题。但是如果这个具体类是稳定的，那么依赖于它就不会出现麻烦。例如，创建string类的实例就不会带来麻烦。因为string类不可能会随时改变，所以依赖于它是很安全的。

　　但是，在一个正在进行的应用程序开发中，有很多具体类都是非常易变的。依赖于它们会带来问题。我们应当依赖于抽象接口，以使我们免受大多数变化的影响。

　　FACTORY模式允许我们只依赖于抽象接口就能创建出具体对象的实例。所以，在正在进行的开发期间，如果具体类是高度易变的，那么该模式是非常有用的。

一个违反了DIP原则的创建具体类的应用程序

　　SomeApp依赖于接口IShape。SomeApp完全通过IShape接口来使用IShape的实例。它没有使用Square类或者Circle类的任何特定方法。但是SomeApp也创建了Square和Circle的实例，因此就不得不依赖于这些具体类。

在SomeApp中应用FACTORY模式

依赖问题

　　上述形式的FACTORY模式存在一个问题。针对每个Shape的派生类，类ShapeFactory都要有一个对应的方法。这就产生了一个仅仅名字上的依赖问题，使得难以增加新的Shape派生类。每当增加一个新的Shape派生类时，都必须要向IShapeFactory接口中增加一个方法。

可替换的工厂

结论

　　使用工厂会带来复杂性，这种复杂性通常是可以避免的，尤其是一个正在演化的设计的初期。如果缺省的使用它们，就会极大地增加扩展设计的难度。为了创建一个新类，就必须要创建出4个新类，这4个类是：2个表示该新类机器工厂的接口类，2个实现这些接口的具体类。

　　工厂是有效的工具。在遵循DIP方面工厂有着重大的作用。它们使得高层策略模块在创建类的实例时无需依赖于这些类的具体实现。它们同样也使得在一组类的完全不同系列的实现间进行交换成为可能。然而，使用工厂会带来复杂性，这种复杂性通常是可以避免的。缺省地使用它们通常不是最好的做法。

 

 

摘录自：[美]RobertC.Martin、MicahMartin著，邓辉、孙鸣译 敏捷软件开发原则、模式与实践（C#版修订版） [M]、人民邮电出版社，2013、323-329、