设计模式之工厂模式（五）

前面几篇，我们已经把简单工厂、工厂方法模式以及抽象工厂模式一一进行了拆解，一步步让我们学会了这几个工厂模式，哦，对了，简单工厂并不算真正意义上的工厂。

我们通过吃披萨的启发，对创建披萨进行了改造；又发展了远景，对披萨加盟有了浓厚的兴趣，并开了很多加盟店；又对材料进行了严格把控，才有了现在的规模。工厂模式，就这样一层层地展现在我们面前。

首先，来看下上次遗留的抽象工厂模式的问题。抽象工厂允许客户使用抽象的接口来创建一组相关的产品，而不需要知道（或关心）实际产出的具体产品是什么。这样一来，客户就从具体的产品中被解耦。让我们看看类图来了解其中的关系。

这是一张相当复杂的类图：让我们从pizzastore的观点来看一看它：

工厂方法是不是潜伏在抽象工厂里面？

我们注意到，抽象工厂的每个方法实际上看起来都像工厂方法。每个方法能被声明称抽象，而子类的方法覆盖这些方法来创建某些对象。

所以，抽象工厂方法经常以工厂方法的方式实现，这很有道理，对吧？抽象工厂的任务是定一个负责创建一组产品的接口。这个接口内的每个方法负责创建一个具体产品，同时我们利用实现抽象工厂的子类来提供这些具体的做法。所以，在抽象工厂中利用工厂方法实现生产方法是相当自然的做法。

比较工厂方法和抽象工厂

因为书中用图描绘了对比的关系，小编力求同书本结合，故在此把书本中的类图贴出来，大家不要介意了。

设计箱内的工具

还是按照之前的套路，总结下工具箱内新增的工具吧

• oo基础

  抽象、封装、继承、多态

• oo原则

  封装变化

  多用组合，少用继承

  针对接口编程，不针对实现编程

  为交互对象之间的松耦合设计而努力

  依赖抽象，不要依赖具体类（我们有了一个新原则，知道我们尽可能地让事情保持抽象）

• oo模式

  『策略模式』、『观察者模式』、『装饰者模式』

  『抽象工厂模式』提供一个接口，用于创建相关或依赖对象的家族，而不需要明确指定具体类

  『工厂方法模式』定义了一个创建对象的接口，但由子类决定要实例化的类是哪一个。工厂方法让类把实例化推迟到子类

结尾

很高兴，听过这么多的篇幅，大家能和我坚持学完。小编知道，针对这个工厂模式，写的不那么尽如人意。篇幅太多，描述不清，可能小编自己的想法加的也不够多，被书本牵着鼻子走了。

所以，针对工厂模式，包括后面更多的模式，小编还是会做下改变。之前说过小编会先总体理解一遍再进行编写，以后可能小编还得列一个大纲先，然后和大家一起学习，一起进步。

小编希望能看到更多的意见和建议，让这个系列写的更好。谢谢大家的支持

爱生活，爱学习，爱感悟，爱挨踢