所属文章系列：寻找尘封的银弹：设计模式精读
【动机】
我所见过的代码中，使用设计模式的并不多。如果这些代码能够做到从容面对变化，那它依然是好代码。
但在实践中，当我们面对需求变化的时候，会发现每次应对变化都需要很大的代码改动量，而且很容易出错。再加上缺少单元测试的保护，只能靠人工测试来验证代码是否有效，有些隐蔽的bug就有可能从程序员、测试员手中溜过，而直接出现在用户那里。
我们都知道改bug的成本远比预防bug的成本要高，同时大部分程序员并不喜欢改bug，尤其是改那种“按下葫芦起了瓢”的bug，所以程序员急需找到一个方法来解决这些令人头疼的问题。
抽象工厂模式就是解决需求变化问题的一种方案。
我们先看一段未使用抽象工厂模式的代码，找找痛点在哪里：
void Client1::DoSomething() {
file = FileAPI::CreateFile();
...
}
void Client2::DoSomething() {
folder = FileAPI::CreateFolder();
...
}
void Client3::DoSomething() {
configFile = FileAPI::CreateConfigFile();
...
}
注：Client1、Client2等是指系统中的某个类，它们使用FileAPI，就称它们为FileAPI的Client或叫客户代码。
从这段代码能看出，我们已经把文件系统的API作了封装，这很好。不过，当需求变化不断地到来时，这些看起来还不错的代码就遇到了麻烦：
1.第一次需求变化
我们现在遇到了一个新需求：为了提供安全机制，需要把系统中使用的所有文件都进行加密。
最直接的方法是：修改FileAPI类的每一个函数的实现代码，例如CreateFile、CreateFolder、CreateConfigFile，把每个函数中原有的不加密代码都删掉，新写一些加密的代码。如果有几十个这样的函数，那工作量就有点大了。
改过代码之后，又发现类名需要修改：FileAPI这个类的意义已经发生了变化，如果不改名，那么在其他程序员修改Clien1、Client2等处代码时，并不知道这些变化，还只是以为FileAPI只是对OS API进行了一个包装而已，那么就有可能写出错误的代码。所以应该把FileAPI类改为EncodedFileSystem，而且所有客户代码都跟着改一遍。
2.第二次需求变化
改完之后，测试通过，交给用户。过了一段时间，又有一个新需求要做：只有在用户设置为“需要加密”时才对文件加密，否则就不加密。
最直接的方法是：把刚才删掉的那些不加密的代码找回来，并在每个函数中加入if判断。就像下边的代码：
void EncodedFileSystem::CreateFile() {
if (userConfig == ENCODED) {
...
} else {
...
}
}
此时，EncodedFileSystem这个类的意义已经发生了变化，所以类名应该再次修改，改为FileSystemWithPolicy。
面对第二次需求变化，大部分的代码修改都是重复性工作，谁喜欢这种编写代码的方式呢？所以有人就在想：有没有一种方法，当我们面对后续的需求变化时，让代码改动量保持最小、最安全？
【模式典型代码】
答案当然是有方法：使用抽象工厂模式。
为了实现抽象工厂，我们需要找到系统初始化部分的代码，例如类MyApplication，在这里写下工厂切换代码：
class MyApplication {
public:
void Initialize() {
if (userConfig == ENCODED)
fileSystemFactory = EncodedFileSystemFactory::GetInstance();
else
fileSystemFactory = FileSystemFactory::GetInstance();
}
FileSystemFactory *GetFileSystemFactory() { return fileSystemFactory; }
private:
FileSystemFactory *fileSystemFactory;
}
class FileSystemFactory {
public:
virtual File *CreateFile();
virtual Folder *CreateFolder();
virtual File *CreateConfigFile();
virtual File *CreateDataFile();
...
}
class EncodedFileSystemFactory : public FileSystemFactory {
public:
virtual File *CreateFile();
virtual Folder *CreateFolder();
virtual File *CreateConfigFile();
virtual File *CreateDataFile();
...
}
如此一来，再有切换文件系统策略的需求，例如一部分文件加密一部分不加密、文件压缩等，那么只需要增加新的实现类，老代码中只需要修改MyApplication::Initialize即可。
当然，客户代码也需要修改一下，例如：
void Client1::DoSomething() {
file = myApplication->GetFileSystemFactory()->CreateFile();
...
}
【优劣对比】
有人会提出疑问：这次使用抽象工厂的代码修改量超过了未使用抽象工厂的代码量。
情况确实如此：
使用抽象工厂的代码量=系统初始化代码的修改 + 新需求引入的新工厂实现类 + 客户代码的修改。
未使用抽象工厂的代码量=系统初始化代码的修改 + 新需求引入的已有类的代码修改。
与未使用抽象工厂的代码相比，使用抽象工厂的代码量确实多出了客户代码的修改部分，代码量虽然有点大，但并不难改，具体来说，把原来的FileAPI类或FileSystemWithPolicy类一删，就会导致编译错误，根据编译错误一一修改即可，简单快捷而且不会出错。
多做了这么一点工作，获得的回报却是很大的：
1.风险小：以后再有需求变化，只需改动系统初始化一处，最多是把新增的类加入进来。反观未使用抽象工厂的代码，它的修改量虽小，但它是在修改已有代码。而修改已有代码的风险远比新增代码要高、测试量也大，这是因为程序员需要花大量的时间去理解被修改代码的影响面，而这个影响面一般都比较大。
2.封装性好：通过GetFileSystemFactory()能看出，客户代码只需要知道有一个工厂来帮我CreateFile，而不需要知道用什么方式实现的，而原来的FileAPI的意思是它直接使用OS API，客户代码需要关心我处于的OS是什么以决定它的调用方式，或者什么时候该切换文件加密策略。
3.单一职责：每个工厂的实现代码非常清晰，互不影响，它只需要关心自己的实现即可。
4.方便单元测试：参见后文的详细讨论。
【模式定义】
抽象工厂模式（Abstract Factory）：提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。
只有当我们希望通过工厂来构造对象时，才是抽象工厂模式，如果只是执行一个函数而不是构造对象，就可能是其他设计模式，例如策略模式。而策略模式也是解决需求变化问题的一种方案。
模式类图
注：该类图是在《设计模式》原书类图的基础上，增加了MyApplication，这样就能更清楚地表达出整个系统的运作关系。另外，AbstractFactory::CreateProductA和AbstractFactory::CreateProductB都应该像AbstractFactory那样以斜体字显示，但我在Visio工具中没有找到那个选项，请读者见谅！
在类图中，我们看到：
1.客户代码（Client）只关心两样东西：工厂、产品。而且这两样东西都是抽象的（Abstract），至于如何实现一个工厂、一个产品，客户不需要关心。
2.而关心使用哪个工厂实现（ConcreteFactory1）的，一般就是系统初始化部分（例如MyApplication::Initialize），也可能是某个设置界面的代码。
3.关心使用哪个产品实现（ProductA1）的，是某个工厂实现（ConcreteFactory1）。通过这种方式实现了一个工厂定制的是一个产品系列（即多个产品），换到另外一个工厂就是另外一个产品系列。
这样就实现了：从系统的某一个视角（例如Client）来看周围环境，它只关心最少的东西，也就是说，它知道的越少，受到各种变化的影响就越小。
【思维进阶（一）：两个维度的变化】
每个设计模式背后都有一些原理在支撑。抽象工厂模式的背后是两个维度的变化：加密或非加密存储、切换文件访问策略。
注：此处的维度可以大致理解为方向。
Marin Fowler在《重构》中提到：“如果某个class经常因为不同的原因在不同的方向上发生变化，Divergent Change就出现了。”Divergent Change是指“发散式变化”，是该书中22种“代码坏味道”中的一种。
前文未使用抽象工厂的FileAPI类代码，受到两个方向的需求变化，即加密或非加密存储、切换文件访问策略的影响，当任意一个需求发生变化时，这个类都要进行修改。它符合“发散式变化”坏味道的定义。
发现了坏味道，就应该去修改，不要让坏味道演变成发酵甚至腐烂。而抽象工厂就是去除“发散式变化”这种坏味道的一种方式。加入工厂代码之后，工厂实现类如EncodedFileSystemFactory只负责加密算法，系统初始化部分如MyApplication::Initialize只负责切换文件访问策略。
在两个维度变化的背后就是单一职责原则，本文不展开对单一职责的讨论。
【思维进阶（二）：灵活运用】
前文的代码，有两点与标准的抽象工厂模式有所区别：
1.把工厂类FileSystemFactory实现为单件。
2.抽象工厂基类FileSystemFactory并不只是一个接口，也包括一个默认实现。
这两条都体现了设计模式的灵活运用方式：并不是完全套用设计模式的标准形式。就像《设计模式》书中62页提到的：
注意MazeFactory仅是工厂方法的一个集合。这是最通常的实现Abstract Factory模式的方式。同时注意MazeFactory不是一个抽象类；因此它既作为AbstractFactory也作为ConcreteFactory。
解释一下：
按照前文类图的定义，AbstractFactory是指抽象基类，它并没有实现代码，ConcreteFactory是指抽象工厂的实现类。
【如何用于单元测试】
工厂模式对于单元测试来说，非常实用。
单元测试，既然叫“单元”，一般只测试一个类，一般是白盒测试。而在实践中，它可以测试多个类，有的测试框架做得比较好，可以让整个应用系统运行起来，就像是用户打开应用程序在使用时一样。
这时，单元测试就变成了集成测试，那我们可测试的范围就大大增加，从而可以模仿用户的行为来测试系统的整体行为，也就是可以使用黑盒测试的手段，此时，白盒测试与黑盒测试结合起来，效果非常好。
为了保证这种系统级别的单元测试代码可以运行起来，不单单需要测试框架的支持，还需要让被测试代码能够使用一些测试数据，而这些测试数据的来源就可以使用偷梁换柱的方法：把真实对象偷偷换成假对象，而这个假对象会提供测试数据，这就是业内流行的Fake或Mock的方式。例如：
class MyApplicationTest {
public:
void Initialize() {
fileSystemFactory = FileSystemFactoryMock::GetInstance();
}
FileSystemFactory *GetFileSystemFactory() { return fileSystemFactory; }
private:
FileSystemFactory *fileSystemFactory;
}
class FileSystemFactoryMock : public FileSystemFactory {
public:
virtual File *CreateFile() { //返回一些假数据，例如File::name = “test1” };
virtual Folder *CreateFolder();
virtual CreateConfigFile();
virtual CreateDataFile();
...
}
void TestCreateFile() {
MyApplicationTest::Initialize();
Client1::DoSomething();
ASSERT(Client1::GetFile()->GetName() == “test1”); //注意：我并不使用完全真实的代码，因为这样表达意图更为明确
}
作于2018-5-11
网友评论