抽象工厂模式[wiki]

以统一塑模语言中的类型图来表示抽象工厂

抽象工厂模式&＃xff08;英语&＃xff1a;Abstract factory pattern&＃xff09;是一种软件开发设计模式。抽象工厂模式提供了一种方式&＃xff0c;可以将一组具有同一主题的单独的工厂封装起来。在正常使用中&＃xff0c;客户端程序需要创建抽象工厂的具体实现&＃xff0c;然后使用抽象工厂作为接口来创建这一主题的具体对象。客户端程序不需要知道&＃xff08;或关心&＃xff09;它从这些内部的工厂方法中获得对象的具体类型&＃xff0c;因为客户端程序仅使用这些对象的通用接口。抽象工厂模式将一组对象的实现细节与他们的一般使用分离开来。

举个例子来说&＃xff0c;比如一个抽象工厂类叫做DocumentCreator&＃xff08;文档创建器&＃xff09;&＃xff0c;此类提供创建若干种产品的接口&＃xff0c;包括createLetter()&＃xff08;创建信件&＃xff09;和createResume()&＃xff08;创建简历&＃xff09;。其中&＃xff0c;createLetter()返回一个Letter&＃xff08;信件&＃xff09;&＃xff0c;createResume()返回一个Resume&＃xff08;简历&＃xff09;。系统中还有一些DocumentCreator的具体实现类&＃xff0c;包括FancyDocumentCreator和ModernDocumentCreator。这两个类对DocumentCreator的两个方法分别有不同的实现&＃xff0c;用来创建不同的“信件”和“简历”&＃xff08;用FancyDocumentCreator的实例可以创建FancyLetter和FancyResume&＃xff0c;用ModernDocumentCreator的实例可以创建ModernLetter和ModernResume&＃xff09;。这些具体的“信件”和“简历”类均继承自抽象类&＃xff0c;即Letter和Resume类。客户端需要创建“信件”或“简历”时&＃xff0c;先要得到一个合适的DocumentCreator实例&＃xff0c;然后调用它的方法。一个工厂中创建的每个对象都是同一个主题的&＃xff08;“fancy”或者“modern”&＃xff09;。客户端程序只需要知道得到的对象是“信件”或者“简历”&＃xff0c;而不需要知道具体的主题&＃xff0c;因此客户端程序从抽象工厂DocumentCreator中得到了Letter或Resume类的引用&＃xff0c;而不是具体类的对象引用。

“工厂”是创建产品&＃xff08;对象&＃xff09;的地方&＃xff0c;其目的是将产品的创建与产品的使用分离。抽象工厂模式的目的&＃xff0c;是将若干抽象产品的接口与不同主题产品的具体实现分离开。这样就能在增加新的具体工厂的时候&＃xff0c;不用修改引用抽象工厂的客户端代码。

使用抽象工厂模式&＃xff0c;能够在具体工厂变化的时候&＃xff0c;不用修改使用工厂的客户端代码&＃xff0c;甚至是在运行时。然而&＃xff0c;使用这种模式或者相似的设计模式&＃xff0c;可能给编写代码带来不必要的复杂性和额外的工作。正确使用设计模式能够抵消这样的“额外工作”。

定义[编辑]

抽象工厂模式的实质是“提供接口&＃xff0c;创建一系列相关或独立的对象&＃xff0c;而不指定这些对象的具体类。”^[1]

使用[编辑]

具体的工厂决定了创建对象的具体类型&＃xff0c;而且工厂就是对象实际创建的地方&＃xff08;比如在C&＃43;&＃43;中&＃xff0c;用“new”操作符创建对象&＃xff09;。然而&＃xff0c;抽象工厂只返回一个指向创建的对象的抽象引用&＃xff08;或指针&＃xff09;。

这样&＃xff0c;客户端程序调用抽象工厂引用的方法&＃xff0c;由具体工厂完成对象创建&＃xff0c;然后客户端程序得到的是抽象产品的引用。如此使客户端代码与对象的创建分离开来。^[2]

因为工厂仅仅返回一个抽象产品的引用&＃xff08;或指针&＃xff09;&＃xff0c;所以客户端程序不知道&＃xff08;也不会牵绊于&＃xff09;工厂创建对象的具体类型。然而&＃xff0c;工厂知道具体对象的类型&＃xff1b;例如&＃xff0c;工厂可能从配置文件中读取某种类型。这时&＃xff0c;客户端没有必要指定具体类型&＃xff0c;因为已经在配置文件中指定了。通常&＃xff0c;这意味着&＃xff1a;

客户端代码不知道任何具体类型&＃xff0c;也就没必要引入任何相关的头文件或类定义。客户端代码仅仅处理抽象类型。工厂确实创建了具体类型的对象&＃xff0c;但是客户端代码仅使用这些对象的抽象接口来访问它们。^[3]
如果要增加一个具体类型&＃xff0c;只需要修改客户端代码使用另一个工厂即可&＃xff0c;而且这个修改通常只是一个文件中的一行代码。不同的工厂创建不同的具体类型的对象&＃xff0c;但是和以前一样返回一个抽象类型的引用&＃xff08;或指针&＃xff09;&＃xff0c;因此客户端代码的其他部分不需要任何改动。这样比修改客户端代码创建新类型的对象简单多了。如果是后者的话&＃xff0c;需要修改代码中每一个创建这种对象的地方&＃xff08;而且需要注意的是&＃xff0c;这些地方都知道对象的具体类型&＃xff0c;而且需要引入具体类型的头文件或类定义&＃xff09;。如果所有的工厂对象都存储在全局的单例对象中&＃xff0c;所有的客户端代码到这个单例中访问需要的工厂&＃xff0c;那么&＃xff0c;更换工厂就非常简单了&＃xff0c;仅仅需要更改这个单例对象即可。^[3]

结构[编辑]

LePUS3图[编辑]

Abstract Factory in LePUS3.png

类图[编辑]

Abstract factory.svg

GuiFactory接口中的createButton方法返回Button类型的对象。返回Button的哪种实现依赖于使用GuiFactory的哪种实现。

需要注意的是&＃xff0c;为了简洁起见&＃xff0c;以上类图仅仅展示了创建一个类型对象的工厂。而在抽象工厂模式中&＃xff0c;通常一个工厂能够创建若干种不同类型的对象。

代码举例[编辑]

假设我们有两种产品接口 Button 和 Border &＃xff0c;每一种产品都支持多种系列&＃xff0c;比如 Mac 系列和 Windows 系列。这样每个系列的产品分别是 MacButton, WinButton, MacBorder, WinBorder 。为了可以在运行时刻创建一个系列的产品族&＃xff0c;我们可以为每个系列的产品族创建一个工厂 MacFactory 和 WinFactory 。每个工厂都有两个方法 CreateButton 和 CreateBorder 并返回对应的产品&＃xff0c;可以将这两个方法抽象成一个接口 AbstractFactory 。这样在运行时刻我们可以选择创建需要的产品系列。

C&＃43;&＃43;[编辑]

我们的产品结构是这样的

class Button; // Abstract Classclass MacButton: public Button {};class WinButton: public Button {};class Border; // Abstract Classclass MacBorder: public Border {};class WinBorder: public Border {};

对应的工厂是这样的

class AbstractFactory {
public:virtual Button* CreateButton() &＃61;0;virtual Border* CreateBorder() &＃61;0;
};class MacFactory: public AbstractFactory {
public:MacButton* CreateButton() { return new MacButton; }MacBorder* CreateBorder() { return new MacBorder; }
};class WinFactory: public AbstractFactory {
public:WinButton* CreateButton() { return new WinButton; }WinBorder* CreateBorder() { return new WinBorder; }
};

那么客户可以根据需要选择 Mac 风格或者 Win 风格来创建 Button 或 Border

AbstractFactory* fac;
switch (style) {
case MAC:fac &＃61; new MacFactory;break;
case WIN:fac &＃61; new WinFactory;break;
}
Button* button &＃61; fac->CreateButton();
Border* border &＃61; fac->CreateBorder();