Aha！设计模式(6)-抽象工厂(5)

协作

• 通常在运行时刻创建（唯一的）一个ConcreteFactory类的实例。这一具体的工厂创建具有特定实现的产品对象。为创建不同的产品对象，客户应使用不同的具体工厂。

 

原书的翻译有一点问题，根据以下的英文原文，作者在这里加上了一个修饰词“唯一的”，这样更准确。另外这里所谓不同的产品对象应该是另外一组产品对象的意思。

 

Normally a single instance of a ConcreteFactory class is created at run-time. This concrete factory creates product objects having a particular implementation. To create different product objects, clients should use a different concrete factory.

 

还有一个问题，这里只是说的是通常怎么怎么样，并没有说一定怎么怎么样。作者认为，这里想表达的是大多数情况下这样就够了，而不是说这个唯一性是抽象工厂模式的必要条件。

 

• AbstractFactory将产品对象的创建延迟到它的ConcreteFactory子类。

 

这句话的难点是对于“延迟”这个词的理解。一般来说创建对象，然后使用对象是正常的步骤。但是使用了抽象工厂以后，Client可以在自己的代码中使用抽象工厂接口生成对象，然后使用该对象。只有这部分代码真正被执行的时候，才需要具象工厂类创建对象。这个时机甚至可以在Client代码发布之后。

 

效果

 

 AbstractFactory模式有下面的一些优点和缺点：
1) 它分离了具体的类 Abstract Factory模式帮助你控制一个应用创建的对象的类。因为一个工厂封装创建产品对象的责任和过程，它将客户与类的实现分离。客户通过它们的抽象接口操纵实例。产品的类名也在具体工厂的实现中被分离；它们不出现在客户代码中。

2) 它使得易于交换产品系列 一个具体工厂类在一个应用中仅出现一次 — 即在它初始化的时候。这使得改变一个应用的具体工厂变得很容易。它只需改变具体的工厂即可使用不同的产品配置，这是因为一个抽象工厂创建了一个完整的产品系列，所以整个产品系列会立刻改变。在我们的用户界面的例子中，我们仅需转换到相应的工厂对象并重新创建接口，就可实现从M o t i f窗口组件转换为Presentation Manager窗口组件。

3) 它有利于产品的一致性 当一个系列中的产品对象被设计成一起工作时，一个应用一次只能使用同一个系列中的对象，这一点很重要。而AbstractFactory很容易实现这一点。

4) 难以支持新种类的产品 难以扩展抽象工厂以生产新种类的产品。这是因为
AbstractFactory接口确定了可以被创建的产品集合。支持新种类的产品就需要扩展该工厂接口，这将涉及AbstractFactory类及其所有子类的改变。我们会在实现一节讨论这个问题的一个解决办法。

 

前面三个是优点，是使用抽象工程模式可以解决的问题，最后一个是缺点。还是以前文中LED显示屏为例：如果想另外支持Font类，需要每个工厂类都增加相应的createFont函数。比较麻烦。

 

关于缺点

任何一种方法都不可能全是优点没有缺点，否则这个世界上就没有其它的方法存在了。

如何在优缺点之间平衡，甚至做到扬长避短，才是体现设计者功力的地方。

 

注：

本文中蓝色粗体文字都引自《设计模式》一书。

 

觉得本文有帮助？请分享给更多人。

阅读更多更新文章，请扫描下面二维码，关注微信公众号【面向对象思考】