[学习笔记]设计模式之Abstract Factory

时间:2022-05-21 17:44:30

写在前面

为方便读者,本文已添加至索引

在上篇笔记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中所提的难处。比如给创建对象的操作增加一个参数;该参数指定了将被创建的对象的种类。不过,这是一种更灵活但不太安全的设计。

写在最后

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