创建模型总结

这个例子感觉比较好，感觉讲抽象问题时最好举例说明，很多人在说模式时都是概念上讲概念，最后很多人只是记住概念，还是不会用。

下面例子原址  http://bbs.chinaunix.net/thread-3585936-1-1.html

这个链接里面的例子很好http://www.cnblogs.com/toutou/p/4899388.html

简单工厂。请注意，简单工厂不是GOF的23种设计模式之一。GOF的23种设计模式中，有两种关于工厂的模式，是工厂方法模式和抽象工厂模式。简单工厂和工厂方法模式不可混为一谈，但是都用到了工厂方法。

    假设你开个汉堡店。
    你写了一个汉堡基类 -- 因为有辣鸡翅汉堡、有甜圈汉堡、有咸鱼汉堡等等。
    完成一个汉堡，有原材料准备prepare、烘烤bake、以及包装package等过程。所有的汉堡制作都要经历这个过程。这些方法在基类中声明。所有的汉堡类都继承并Override这些方法。

    现在你要写一个订购汉堡的函数，如果有客户要订购汉堡，调这个订购函数就可以了。问题是有各种各样的汉堡。于是，根据汉堡的类型，你需要new不同的汉堡。但是，除了new之外所有的代码都是一样的：原料准备，烘烤，包装。只要知道是什么类型的汉堡，那种类型的汉堡就知道怎么完成整个过程(嗯，虚函数)。

1. void order_hamburger(string& HB_type)
   
2. {
   
3.     Hamburger* hb;
   
4.     if (HB_type == 辣鸡) {
   
5.         hb = new 辣鸡汉堡;
   
6.     } else if (HB_type == 咸鱼) {
   
7.         hb = new 咸鱼汉堡;
   
8.     } else if () {
   
9.         ...
   
10.     } 
    
11. 
    
12.     hb->prepare();
    
13.     hb->bake();
    
14.     hb->package();  
    
15. }

复制代码

你写了一大堆if else。这可不好，一旦汉堡的种类有变化，你就得重新维护order_hamburger方法。不止order_hamburger，还有类似于order_hamburger这种根据类型来判断new什么对象的方法 -- 你都需要重写。可能复制粘贴是个好办法...

    稍微好一点的，就是写一个工厂类，里面放一个工厂方法：

1. class HBFactory {
   
2.   Hamburger* createHB(string& HB_type)
   
3.   {
   
4.       Hamburger* hb;
   
5.       if (HB_type == 辣鸡) {
   
6.          hb = new xxx;
   
7.       } else if ( ) {
   
8.          ...
   
9.       }
   
10.          ...
    
11.       return hb;
    
12.   }
    
13. };

复制代码

这样，order_hamberger就可以这样写了：

1. order_hamburger(string& HB_type)
   
2. {
   
3.     HBFactory HBfactory;
   
4.     Hamburger* hb = HBfactory.createHB(HB_type);
   
5. 
   
6.     hb->prepare();
   
7.     hb->bake();
   
8.     hb->package();  
   
9. }

复制代码

order_hamburger方法永远不需要变动。一旦有改变，改变那个Factory就可以了。

    你说，这不过是把if-else移到HBFactory里面而已。没错，只是类似于order_hamburger的方法都可以使用这个工厂，所以避免了代码重复。所有的if-else变化，都统一放到这个工厂类的工厂方法里了。
    这使得，代码可能变化的部分被独立出来。独立到这个工厂类中了。设计模式中所谓“封装变化”，就是指将变化的部分独立出来，这样一旦有变化发生，改动一处就可以了，而不是处处复制粘贴，一旦疏忽就出错。

    嗯，上面的就是简单工厂类了(不是GOF收录的设计模式，只是常用而已)。工厂方法模式，就是在基类中定义一个工厂方法，所有的继承类都重写这个工厂方法，由子类来决定究竟实例化哪一个。抽象工厂模式，则可以创建交叉的产品族。

我的总结：

1 工厂模式都主要的目标是将“产品的’实现‘脱离客户代码“，这样当产品实现更改时，只要产品接口不变，我们客户区代码不受影响。

2 简单工厂模式是一个工厂产生具有共同父类的产品。产生产品的接口会有一个判别产品类别的参数。但我们扩展产品时（如果我们产品变化时，可能影响当别的产品的逻辑（我自己单纯的想法，可能有误）），我们需要更改该接口的实现。违反了设计模式的”闭开原则“

3 工厂模式是将具体产品的实现延迟到工厂的子类里面，这样我们扩展产品时，只需要添加相应的具体工厂即可（这句话确实总结了工厂模式的思想）。

4 工厂模式效果1GOF P72理解，为子类提供挂钩：当我们不同子类需要初始化父类的一些成员时，可能不同的子类的缺省实现都不相同，工厂模式可以将这些缺省的初始化放置于子类的工厂里面，以避免客户区代码出现父类一些缺省初始化的代码。

5 工厂模式效果2GOF P72连接平行的类层次：当我们一个类A需要将一些职责委托给类B时，（类A与B的关联性应该很低），类A可以定义一个工厂方法，具体的类A1,A2的工厂方法产生具体的工具类B1,B2，而不必让类A具有类B的成员。

6 工厂模式的效果3， 当我们客户区代码原有的基础上，需要增加新的类，我们可以在实现一个具体的类，在原有的基础的代码上，增加我们新类的逻辑判别和处理，不必修改原来的代码。 （感觉和4的目的一样，还是把父类的成员初始化放到了子类里面）

7 抽象工厂模式是将工厂模式进一步扩展（这句话应该是错的），一个工厂可以生产更多的不同大类的产品。应该这些大类的产品应该汇集起来组成某种功能，例如自行车，我需要轮子，车架，刹车等部件组成。这些轮子，车架。。。也都是大类，我们可以定义不同具体的轮子。来标志不同的车。

8 抽象工厂模式一般代表我们的应用，该应用需要一些大的类的对象，代表我们的应用，需要和单例模式结合，即定义一个工厂。当抽象工厂里面的产品具体时，我们的应用也具体了。

9 创建模型就是因为我们对象的创建过程太过负责了，而且可以分为几个步骤，我们可以设计一个builder类来管理创建过程，用director类里面用一个builder成员来指挥build的创建步骤。最终director给客户实现该产品创建的过程。

10 原型模式，就是用对象创建对象，主要是一些对象的创建过程和某些具体应用知道运行时刻才能关联起来。比如我们的工具栏，就是为了添加，删除一些元素，但我们用工厂模式为这些操作和元素组装起来，这样类会膨胀。我们应该在对应操作里面用原型模式来复制对象，利用对象生成一些对象。

11 单例模式，目前理解只是用来创建全局只能有一个对象的模式。

 

5 闭开原则的链接。 http://blog.csdn.net/zhengzhb/article/details/7296944。