[学习笔记]设计模式之Abstract Factory
写在前面
为方便读者,本文已添加至索引:
在上篇笔记Builder设计模式中,时の魔导士祭出了自己的WorldCreator。尽管它因此能创造出一个有山有树有房子的世界,但是白雪公主的生活似乎并不太快乐。啊,她当然需要填饱肚子。“来点可口的意式甜点,还是独特的法式面包呢?”魔导士心想。顺便说一下,白雪公主是德国人。“那就德式烤肠怎么样?……总之,我们需要点食品加工厂~尝尝来自世界各地的美味吧!”
来自不同地域的食品加工厂各自有着独特的工艺水平,生产出来的食物口感味道上都各有千秋。但它们生产出来的都是给公主吃的食物,要怎么样去设计这个食物的供给呢?我们当然可以采用Abstract Factory(抽象工厂)模式啦!
要点梳理
- 目的分类
- 对象创建型模式
- 范围准则
- 对象(该模式处理对象间的关系,这些关系在运行时刻是可以变化的,更具动态性)
- 主要功能
- 提供一个创建一系列相关或相互依赖对象的接口,而无需指定它们具体的类。
- 适用情况
- 一个系统要独立于它的产品的创建、组合和表示时
- 一个系统要由多个产品系列中的一个来配置时
- 当我们要强调一系列相关的产品对象的设计以便进行联合使用时
- 当我们提供一个产品类库,而只想显示它们的接口而不是实现时
- 参与部分
- AbstractFactory:声明一个创建抽象产品对象的操作接口
- ConcreteFactory:实现创建具体产品对象的操作
- AbstractProduct:为一类产品对象声明一个接口
- ConcreteProduct:定义一个将被相应的具体工厂创建的产品对象;实现AbstractProduct接口
- Client:仅使用由AbstractFactory和AbstractProduct类声明的接口
- 协作过程
- 通常在运行时刻创建一个ConcreteFactory类的实例。这一具体的工厂创建具有特定实现的产品对象。为创建不同的产品对象,客户应使用不同的具体工厂
- AbstractFactory将产品对象的创建延迟到它的ConcreteFactory
示例分析 - 美味的食品工厂
时の魔导士合上了他心爱的魔法书。为了让白雪公主能随时随地吃上美味的食物,他在公主的城堡外建造了一个充满魔法的FoodFactory(魔法总是虚幻的,可以认为它只是一个Abstract Factory),它能创造食物Food和饮料Drink,请看示例:
1 class FoodFactory { 2 public: 3 FoodFactory(); 4 5 virtual Dinner* makeDinner() const { return new Dinner(); } 6 virtual Food* makeFood(int f) const { return new Food(f); } 7 virtual Drink* makeDrink(int d) const { return new Drink(d); } 8 }
他当然还教会7个霍比特人中的一个生产食物的咒语(createFood),以使得他荣幸地成为白雪公主的第一任美味厨师长。createFood方法以FoodFactory为参数,这样小霍比特人就能指定要制作的食物和饮料了:
1 Dinner* Hobbit::createFood (FoodFactory& factory) { 2 Dinner* dinner = factory.makeDinnner(); 3 Food* food = factory.makeFood(9); 4 Drink* drink = factory.makeDrink(9); 5 6 dinner->addFoodAndDrink(food, drink); 7 8 return dinner; 9 }
等等,怎么是9份?啊,白雪公主要吃霍比特人2倍的量哦。另外,时の魔导士悄悄地告诉小霍比特人,其实FoodFactory只是一个统一的魔法平台而已,想要让白雪公主尝到世界各地的美味,他还需要建造相应的具体工厂,比如说“PizzaHut”:
1 class PizzaHut : public FoodFactory { 2 public: 3 PizzaHut(); 4 5 virtual Food* makeFood(int f) const { return new Pizza(f, addCheese()); } 6 virtual Drink* makeDrink(int d) const { return new Coffee(d); } 7 protected: 8 Cheese* addCheese() const; 9 }
嗯……更多芝士,更多美味~~“当然,你甚至可以来点中餐!”时の魔导士兴奋地说道:
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, 52); } }
现在,我们可以看到Abstract Factory的好处了,如果白雪公主想吃意式菜:
1 Hobbit theCook; 2 PizzaHut factory; 3 Dinner* dinner = theCook.createFood(factory);
那如果她突然想吃中餐,要做的仅仅是:
1 Hobbit theCook; 2 ChineseRestaurant factory; 3 Dinner* dinner = theCook.createFood(factory);
总而言之,现在他们可以享受到美味的食物啦。
特点总结
趁着白雪公主她们一行人吃饭的时间,我们来回顾一下抽象工厂的特点和实用性吧。在上面的例子中,客户即是霍比特人厨师,工厂则是FoodFactory, PizzaHut, ChineseRestaurant,产品是Dinner(Food和Drink的合集)。注意到FoodFactory仅是工厂方法的一个集合。这是最通常的实现Abstract Factory模式的方式。同时注意FoodFactory不是一个抽象类;因此它既作为AbstractFactory也作为ConcreteFactory。这是Abstract Factory模式的简单应用的另一个通常的实现。因为FoodFactory是一个完全由工厂方法组成的具体类,通过生成一个子类并重定义需要改变的操作,它很容易生成一个新的FoodFactory。我们可以看到:
- 它分离了具体的类。Abstract Factory模式帮助我们控制一个应用创建的对象的类。因为一个工厂封装创建产品对象的责任和过程,它将客户与类的实现分离。客户通过它们的抽象接口操纵实例。产品的类名也在具体工厂的实现中被分离;它们不出现在客户代码中。
- 它使得易于交换产品系列。一个具体工厂类在一个应用中仅出现一次—即在它初始化的时候。这使得改变一个应用的具体工厂变得很容易。它只需改变具体的工厂即可使用不同的产品配置,这是因为一个抽象工厂创建了一个完整的产品系列,所以整个产品系列会立刻改变。上文的例子已经提到。
- 它有利于产品的一致性。当一个系列中的产品对象被设计成一起工作时,一个应用一次只能使用同一个系列中的对象,这一点很重要。而Abstract Factory可以很容易实现这一点。
- 难以支持新种类的产品。难以扩展抽象工厂以生产新种类的产品。这是因为AbstractFactory接口确定了可以被创建的产品集合。支持新种类的产品就需要扩展该工厂接口,这将涉及AbstractFactory类及其所有子类的改变。比方说上面的例子,Dinner中除了Food和Drink,我还想要点Dessert……
当然我们可以定义一个可扩展的工厂,来解决4中所提的难处。比如给创建对象的操作增加一个参数;该参数指定了将被创建的对象的种类。不过,这是一种更灵活但不太安全的设计。
写在最后
今天的笔记就到这里了,欢迎大家批评指正!如果觉得可以的话,好文推荐一下,我会非常感谢的!