设计模式推演——创建型模式

上一篇文章中提到，在做代码设计时，坚持OCP原则，坚持一起从需求分析开始，分析当前代码中哪些是不变的，哪些是变化的，那么我们就可以做到简单而快速的响应客户需求。现在，我们来讨论创建型模式

还是从需求分析开始，使用创建型模式，实际是为了将类名和类的创建解耦。换成变与不变的说法就是，产品名称可能经常发生变化或者有扩充，但是这些产品对象的使用方式不变。

假设我们现在有产品类Wall（A，B，...）和 Door（A，B， ...）, 以及使用产品的类MazeGame ( 这里借用了《DesignPattern》一书中一些对象名称，但设计上有略微不同)

1.   对类的创建用一个工厂类或者工厂方法【封装】，这就得到了简单工厂模式。

2.  进一步，对上面的 工厂类应用【多态化】，这就得到了抽象工厂模式

3.  再进一步，实际上我们最终要得到的产品是Maze对象，假设Maze产品的组装是比较复杂但方法是固定不变的，只是构成的组件Wall和Door有变化，那么可以进一步将Maze的组装过程也【封装】起来，得到builder模式。

     当然，应用builder模式时，我们实际上还会基于一个因素：易用性。  builder模式是将产品一个组建一个组件的构造，每个组件的构造可能都有不同的参数。如果直接使用一个方法创建，那么就要一下子传入很多参数，这是种很难使用的代码。

4. 直接对MazeGame中的buildMaze（）应用多态化，就可以得到FactoryMethod。  

（当然实际上若只是为了Maze的创建，而构造下面这样一个继承体系，可不是个好主意。一般会考虑子类中有更多的需要重写的行为时，才会应用工厂方法）

5. 其他几种创建型模式，并没有应用什么设计原则，

    像Prototype模式，只是为了实现 虚拷贝构造函数 的效果

       Singleton模式， 只是为了保证变量必定被初始化，或者 类实例的唯一性。

6. 创建型模式与重构

如果需要在已有代码中通过重构引入创建型模式，有两点需要考虑的：

1. 结构上不难实现，只是比较麻烦，需要找到各种分散的new XXX（）代码， 先以某个静态创建方法代替。

2. 这项重构很多时候是安全的，即使没有找全，至少原来代码创建的还是正确的对象。

具体重构细节，可以参考《重构——改善既有代码的设计》一书中  ExtractSubclass, ExtractClass,  Replace Typecode with Subclass/State 这四个方法。

忘了再次强调一下，引入创建型模式是为了将对象的创建与对象的使用解耦，正如上面所展示的，当增加新的产品类 DoorC、WallC时，虽然需要对现有工厂类进行修改（都只是扩展），但是对产品的使用类MazeGame，则不需要做任何变更。