Abstract Factory(抽象工厂)——对象创建型模式
意图:提供一个创建一系列相关或相互依赖对象的接口,而无需指定它们具体的类。
适用性:
[list]
[*]一个系统要独立于它的产品的创建、组合和表示时。
[*]一个系统要由多个产品系列中的一个来配置时。
[*]当你要强调一系列相关的产品对象的设计以便进行联合使用是。
[*]当你提供一个产品类库,而只想显示它们的接口而不是实现时。
[/list]
结构:
[img]http://dl.iteye.com/upload/picture/pic/110429/4e991e56-6f6f-364a-b12a-12652c22caa5.jpg[/img]
参与者:
[list]
[*] AbstractFactory
声明一个创建抽象产品对象的操作接口。
[*] ConcreteFactory
实现创建具体产品对象的操作。
[*] AbstractProduct
为一类产品对象声明一个接口。
[*] ConcreteProduct
定义一个将被相应的具体工厂创建的产品对象。
实现AbstractProduct接口。
[*] Client
仅使用由AbstractFactory和AbstractProduct类声明的接口。
[/list]
协作:
通常在运行时刻创建一个ConcreteFactory类的实例。这一具体的工厂创建具有特定实现的产品对象。为创建不同的产品对象,客户应使用不同的具体工厂。
AbstractFactory将产品对象的创建延迟到它的ConcreteFactory子类。
效果:
AbstractFactory模式有下面的一些优点和缺点:
优点:
[list=1]
[*] 它分离了具体的类
因为一个工厂封装创建产品对象的责任和过程,它将客户与类的实现分离。客户通过它们的抽象接口操纵实例。
产品的类名也在具体工厂的实现中被分离;它们不出现在客户代码中。
[*] 它使得易于交换产品系列
一个具体工厂类在一个应用中只出现一次——即在它初始化的时候。这使得改变一个应用的具体工厂变得很容易。
[*] 它有利于产品的一致性
当一个系列中的产品对象被设计成一起工作时,一个应用一次只能使用同一个系列中的对象,这一点很重要。
[/list]
缺点:
难以支持新种类的产品:难以扩展抽象工厂以生产心种类的产品。因为接口一旦确定,并且使用,未来很难扩展该接口,因为这涉及到所有实现类的修改,是产品设计中的大忌(在《Effective Java》中有提到)。
代码示例:
考虑一个支持多种视感(look-and-feel)标准的用户界面工具包,例如MotifManager和PresentationManager。不同的视感风格为诸如滚动条、窗口和按钮等用户界面“窗口组件”定义不同的外观和行为。为保证视感风格标准件的可移植性,一个应用不应该为一个特定的视感外观硬编码它的窗口组件。在整个应用中实例化特定视感风格的窗口组件类将使得以后很难改变视感风格。
AbstractFactory:
ConcreteFactory1:
ConcreteFactory2:
AbstractProduct:
ConcreteProduct1:
ConcreteProduct2:
Client:
在Client中,我们通过抽象工厂(WidgetFactory),来返回抽象产品(Window,ScrollBar)。
完。
意图:提供一个创建一系列相关或相互依赖对象的接口,而无需指定它们具体的类。
适用性:
[list]
[*]一个系统要独立于它的产品的创建、组合和表示时。
[*]一个系统要由多个产品系列中的一个来配置时。
[*]当你要强调一系列相关的产品对象的设计以便进行联合使用是。
[*]当你提供一个产品类库,而只想显示它们的接口而不是实现时。
[/list]
结构:
[img]http://dl.iteye.com/upload/picture/pic/110429/4e991e56-6f6f-364a-b12a-12652c22caa5.jpg[/img]
参与者:
[list]
[*] AbstractFactory
声明一个创建抽象产品对象的操作接口。
[*] ConcreteFactory
实现创建具体产品对象的操作。
[*] AbstractProduct
为一类产品对象声明一个接口。
[*] ConcreteProduct
定义一个将被相应的具体工厂创建的产品对象。
实现AbstractProduct接口。
[*] Client
仅使用由AbstractFactory和AbstractProduct类声明的接口。
[/list]
协作:
通常在运行时刻创建一个ConcreteFactory类的实例。这一具体的工厂创建具有特定实现的产品对象。为创建不同的产品对象,客户应使用不同的具体工厂。
AbstractFactory将产品对象的创建延迟到它的ConcreteFactory子类。
效果:
AbstractFactory模式有下面的一些优点和缺点:
优点:
[list=1]
[*] 它分离了具体的类
因为一个工厂封装创建产品对象的责任和过程,它将客户与类的实现分离。客户通过它们的抽象接口操纵实例。
产品的类名也在具体工厂的实现中被分离;它们不出现在客户代码中。
[*] 它使得易于交换产品系列
一个具体工厂类在一个应用中只出现一次——即在它初始化的时候。这使得改变一个应用的具体工厂变得很容易。
[*] 它有利于产品的一致性
当一个系列中的产品对象被设计成一起工作时,一个应用一次只能使用同一个系列中的对象,这一点很重要。
[/list]
缺点:
难以支持新种类的产品:难以扩展抽象工厂以生产心种类的产品。因为接口一旦确定,并且使用,未来很难扩展该接口,因为这涉及到所有实现类的修改,是产品设计中的大忌(在《Effective Java》中有提到)。
代码示例:
考虑一个支持多种视感(look-and-feel)标准的用户界面工具包,例如MotifManager和PresentationManager。不同的视感风格为诸如滚动条、窗口和按钮等用户界面“窗口组件”定义不同的外观和行为。为保证视感风格标准件的可移植性,一个应用不应该为一个特定的视感外观硬编码它的窗口组件。在整个应用中实例化特定视感风格的窗口组件类将使得以后很难改变视感风格。
AbstractFactory:
public interface WidgetFactory {
public Window createWindow();
public ScrollBar createScrollBar();
}
ConcreteFactory1:
public class MotlfWidgetFactory implements WidgetFactory {
@Override
public ScrollBar createScrollBar() {
return new MoltfScrollBar();
}
@Override
public Window createWindow() {
return new MoltfWindow();
}
}
ConcreteFactory2:
public class PMWidgetFactory implements WidgetFactory {
@Override
public ScrollBar createScrollBar() {
return new PMScrollBar();
}
@Override
public Window createWindow() {
return new MoltfWindow();
}
}
AbstractProduct:
public interface ScrollBar {
}
public interface Window {
}
ConcreteProduct1:
public class MoltfScrollBar implements ScrollBar {
}
public class MoltfWindow implements Window {
}
ConcreteProduct2:
public class PMScrollBar implements ScrollBar{
}
public class PMWindow implements Window{
}
Client:
public Window getWindow(WidgetFactory widgetFactory) {
return widgetFactory.createWindow();
}
public ScrollBar getScrollBar(WidgetFactory widgetFactory) {
return widgetFactory.createScrollBar();
}
在Client中,我们通过抽象工厂(WidgetFactory),来返回抽象产品(Window,ScrollBar)。
完。