写在前面

在上篇笔记Builder设计模式中，时の魔导士祭出了自己的WorldCreator。尽管它因此能创造出一个有山有树有房子的世界，但是白雪公主的生活似乎并不太快乐。啊，她当然需要填饱肚子。“来点可口的意式甜点，还是独特的法式面包呢？”魔导士心想。顺便说一下，白雪公主是德国人。“那就德式烤肠怎么样？……总之，我们需要点食品加工厂~尝尝来自世界各地的美味吧！”

来自不同地域的食品加工厂各自有着独特的工艺水平，生产出来的食物口感味道上都各有千秋。但它们生产出来的都是给公主吃的食物，要怎么样去设计这个食物的供给呢？我们当然可以采用Abstract Factory（抽象工厂）模式啦！

要点梳理

• 目的分类
  • 对象创建型模式
• 范围准则
  • 对象（该模式处理对象间的关系，这些关系在运行时刻是可以变化的，更具动态性）
• 主要功能
  • 提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。
• 适用情况
  • 一个系统要独立于它的产品的创建、组合和表示时
  • 一个系统要由多个产品系列中的一个来配置时
  • 当我们要强调一系列相关的产品对象的设计以便进行联合使用时
  • 当我们提供一个产品类库，而只想显示它们的接口而不是实现时
• 参与部分
  • AbstractFactory：声明一个创建抽象产品对象的操作接口
  • ConcreteFactory：实现创建具体产品对象的操作
  • AbstractProduct：为一类产品对象声明一个接口
  • ConcreteProduct：定义一个将被相应的具体工厂创建的产品对象；实现AbstractProduct接口
  • Client：仅使用由AbstractFactory和AbstractProduct类声明的接口
• 协作过程
  • 通常在运行时刻创建一个ConcreteFactory类的实例。这一具体的工厂创建具有特定实现的产品对象。为创建不同的产品对象，客户应使用不同的具体工厂
  • AbstractFactory将产品对象的创建延迟到它的ConcreteFactory

示例分析 - 美味的食品工厂

时の魔导士合上了他心爱的魔法书。为了让白雪公主能随时随地吃上美味的食物，他在公主的城堡外建造了一个充满魔法的FoodFactory（魔法总是虚幻的，可以认为它只是一个Abstract Factory），它能创造食物Food和饮料Drink，请看示例：

 class FoodFactory {

 public:

     FoodFactory();

     virtual Dinner* makeDinner() const { return new Dinner(); }

     virtual Food* makeFood(int f) const { return new Food(f); }

     virtual Drink* makeDrink(int d) const { return new Drink(d); }

 }

他当然还教会7个霍比特人中的一个生产食物的咒语（createFood），以使得他荣幸地成为白雪公主的第一任美味厨师长。createFood方法以FoodFactory为参数，这样小霍比特人就能指定要制作的食物和饮料了：

 Dinner* Hobbit::createFood (FoodFactory& factory) {

     Dinner* dinner = factory.makeDinnner();

     Food* food = factory.makeFood();

     Drink* drink = factory.makeDrink();

     dinner->addFoodAndDrink(food, drink);

     return dinner;

 }

等等，怎么是9份？啊，白雪公主要吃霍比特人2倍的量哦。另外，时の魔导士悄悄地告诉小霍比特人，其实FoodFactory只是一个统一的魔法平台而已，想要让白雪公主尝到世界各地的美味，他还需要建造相应的具体工厂，比如说“PizzaHut”：

 class PizzaHut : public FoodFactory {

 public:

     PizzaHut();

     virtual Food* makeFood(int f) const { return new Pizza(f, addCheese()); }

     virtual Drink* makeDrink(int d) const { return new Coffee(d); }

 protected:

     Cheese* addCheese() const;

 }

嗯……更多芝士，更多美味~~“当然，你甚至可以来点中餐！”时の魔导士兴奋地说道：

class ChineseRestaurant : public FoodFactory {

public:

    ChineseRestaurant();

    virtual Food* makeFood(int f) const { return new ChineseFood(f, "Egg Fried Rice"); }

    virtual Drink* makeDrink(int d) const { return new Maotai(d, ); }

}

现在，我们可以看到Abstract Factory的好处了，如果白雪公主想吃意式菜：

 Hobbit theCook;

 PizzaHut factory;

 Dinner* dinner = theCook.createFood(factory);

那如果她突然想吃中餐，要做的仅仅是：

 Hobbit theCook;

 ChineseRestaurant factory;

 Dinner* dinner = theCook.createFood(factory);

总而言之，现在他们可以享受到美味的食物啦。

特点总结

趁着白雪公主她们一行人吃饭的时间，我们来回顾一下抽象工厂的特点和实用性吧。在上面的例子中，客户即是霍比特人厨师，工厂则是FoodFactory, PizzaHut, ChineseRestaurant，产品是Dinner（Food和Drink的合集）。注意到FoodFactory仅是工厂方法的一个集合。这是最通常的实现Abstract Factory模式的方式。同时注意FoodFactory不是一个抽象类；因此它既作为AbstractFactory也作为ConcreteFactory。这是Abstract Factory模式的简单应用的另一个通常的实现。因为FoodFactory是一个完全由工厂方法组成的具体类，通过生成一个子类并重定义需要改变的操作，它很容易生成一个新的FoodFactory。我们可以看到：

1. 它分离了具体的类。Abstract Factory模式帮助我们控制一个应用创建的对象的类。因为一个工厂封装创建产品对象的责任和过程，它将客户与类的实现分离。客户通过它们的抽象接口操纵实例。产品的类名也在具体工厂的实现中被分离；它们不出现在客户代码中。
2. 它使得易于交换产品系列。一个具体工厂类在一个应用中仅出现一次—即在它初始化的时候。这使得改变一个应用的具体工厂变得很容易。它只需改变具体的工厂即可使用不同的产品配置，这是因为一个抽象工厂创建了一个完整的产品系列，所以整个产品系列会立刻改变。上文的例子已经提到。
3. 它有利于产品的一致性。当一个系列中的产品对象被设计成一起工作时，一个应用一次只能使用同一个系列中的对象，这一点很重要。而Abstract Factory可以很容易实现这一点。
4. 难以支持新种类的产品。难以扩展抽象工厂以生产新种类的产品。这是因为AbstractFactory接口确定了可以被创建的产品集合。支持新种类的产品就需要扩展该工厂接口，这将涉及AbstractFactory类及其所有子类的改变。比方说上面的例子，Dinner中除了Food和Drink，我还想要点Dessert……

当然我们可以定义一个可扩展的工厂，来解决4中所提的难处。比如给创建对象的操作增加一个参数；该参数指定了将被创建的对象的种类。不过，这是一种更灵活但不太安全的设计。

写在最后

今天的笔记就到这里了，欢迎大家批评指正！如果觉得可以的话，好文推荐一下，我会非常感谢的！