第一次在blog上写技术性的文章，希望可以坚持。
总体上说，创建型模式，就是将你不关心的地方，用一个类封装起来，比如你盖房子不会关心砖头
怎么搞出来的，装配汽车不关心轮胎怎么出来的，反正符合一定的规范，拿来就用。这个规范出厂都检验过了，不用担心。
这个出厂检验，就类似于大量使用的继承机制，该机制保证了只要继承于制定好的规范--基类，都可以用。不然编译也过不了。
1。抽象工厂。只负责给出符合规范的东西。这些东西怎么组装不管了。例如装配汽车的时候，有一个专门负责取零件的人，就是负责创建不同对象的类拉。装配工对他说，给我四个轮胎，一个车顶。他负责完成这些动作，装配工也不管轮胎他怎么变出来的，蒙头装配就好了。这样一来，装配宝马，就和负责去宝马相关配件的人打交道；如果装配的是奔驰，就和负责取奔驰的人打交道。
2。builder模式。其实和抽象工厂和类似的，不过他的责任更重大，除了取出不同的零件外，还负责把这些零件装配好。例如装配电脑的时候，有一个人负责生产主板。如果是抽象工厂模式，那么你得问他要100个电容，20个引脚什么的，还得自己焊。而builder模式就愉快了，只要和他打个招呼，哥们，装个主板。那么你看到的就是一个把电容，电线什么搞定的主板了。这样一来省了很多事情，可是这样也失去了发挥的空间。这个取舍是看具体需要了。
3。原型模式。其实就是把抽象工厂改成了template化。抽象工厂里面实用宝马的轮胎和奔驰的轮胎，需要找不同的人的。那天工厂资金紧张，把负责取出宝马轮胎的人辞退了，就剩下一个，那么按照抽象工厂的观念就不够了。怎么办呢？只好加强它的训练，让他除了可以认出奔驰的轮胎外，还可以识别奔驰的轮胎。这样，两边的装配工人在问他要轮胎的时候，说“给我四个轮胎”，这句话会让他郁闷的，必须说我要“奔驰轮胎”或者“宝马轮胎”才可以拿到自己想要得。这样的好处是以后多装配一种汽车的时候，只需要对负责去轮胎的人进行训练，如果他头脑好用的话。而无需再请一个人多花费了。不过，这样的问题在于，没个装配工都必须知道自己在干吗，万一本来是装配宝马调到装配奔驰的地方了，一时改不了口，还是嚷嚷“宝马”轮胎，拿这个汽车就麻烦了。负责取出轮胎的人是没有责任的。这个责任转移了。各有千秋，看是否需要了。如果本来就一两种汽车要装配，那根本无须这种风险。可是万一装配100种汽车，那就不一样了，可以省掉99个人力成本和管理成本，很爽哦。
