提供一个创建一系列相关或相互依赖对象的接口,而无需指定它们具体的类。
考虑一个支持多种视感( l o o k - a n d - f e e l)标准的用户界面工具包,例如M o t i f和Presentation Manager。不同的视感风格为诸如滚动条、窗口和按钮等用户界面“窗口组件”定义不同的外观和行为。为保证视感风格标准间的可移植性,一个应用不应该为一个特定的视感外观硬编码它的窗口组件。在整个应用中实例化特定视感风格的窗口组件类将使得以后很难改变视感风格。
为解决这一问题我们可以定义一个抽象的Wi d g e t F a c t o r y类,这个类声明了一个用来创建每一类基本窗口组件的接口。每一类窗口组件都有一个抽象类,而具体子类则实现了窗口组件的特定视感风格。对于每一个抽象窗口组件类, Wi d g e t F a c t o r y接口都有一个返回新窗口组件对象的操作。客户调用这些操作以获得窗口组件实例,但客户并不知道他们正在使用的是哪些具体类。这样客户就不依赖于一般的视感风格,如下页图所示。
每一种视感标准都对应于一个具体的Wi d g e t F a c t o r y子类。每一子类实现那些用于创建合适视感风格的窗口组件的操作。例如, M o t i f Wi d g e t F a c t o r y的C r e a te S c r o l l B a r操作实例化并返回一个M o t i f滚动条,而相应的P M Wi d g e t F a c t o r y操作返回一个Presentation Manager的滚动条。客户仅通过Wi d g e t F a c t o r y接口创建窗口组件,他们并不知道哪些类实现了特定视感风格的窗口组件。换言之,客户仅与抽象类定义的接口交互,而不使用特定的具体类的接口。Wi d g e t F a c t o r y也增强了具体窗口组件类之间依赖关系。一个M o t i f的滚动条应该与M o t i f按钮、M o t i f正文编辑器一起使用,这一约束条件作为使用M o t i f Wi d g e t F a c t o r y的结果被自动加上。
适用性
在以下情况可以使用Abstract Factory模式
• 一个系统要独立于它的产品的创建、组合和表示时。
• 一个系统要由多个产品系列中的一个来配置时。
• 当你要强调一系列相关的产品对象的设计以便进行联合使用时。
• 当你提供一个产品类库,而只想显示它们的接口而不是实现时。
5. 结构
此模式的结构如下图所示。
效果
A b s t r a c t F a c t o r y模式有下面的一些优点和缺点:
1) 它分离了具体的类Abstract Factory模式帮助你控制一个应用创建的对象的类。因为一个工厂封装创建产品对象的责任和过程,它将客户与类的实现分离。客户通过它们的抽象接口操纵实例。产品的类名也在具体工厂的实现中被分离;它们不出现在客户代码中。
2) 它使得易于交换产品系列一个具体工厂类在一个应用中仅出现一次—即在它初始化的时候。这使得改变一个应用的具体工厂变得很容易。它只需改变具体的工厂即可使用不同的产品配置,这是因为一个抽象工厂创建了一个完整的产品系列,所以整个产品系列会立刻改变。在我们的用户界面的例子中,我们仅需转换到相应的工厂对象并重新创建接口,就可实现从M o t i f窗口组件转换为Presentation Manager窗口组件。
3) 它有利于产品的一致性当一个系列中的产品对象被设计成一起工作时,一个应用一次只能使用同一个系列中的对象,这一点很重要。而A b s t r a c t F a c t o r y很容易实现这一点。
4) 难以支持新种类的产品难以扩展抽象工厂以生产新种类的产品。这是因为A b s t r a c t F a c t o r y接口确定了可以被创建的产品集合。支持新种类的产品就需要扩展该工厂接口,这将涉及A b s t r a c t F a c t o r y类及其所有子类的改变。我们会在实现一节讨论这个问题的一个解决办法。