建造者模式

1. 一步步来哈，现在要造一个房子，需要建地板，墙壁和屋顶，有碧桂园和中铁可以建
   1. 首先应该有一个房子类
   2. 
   3. 应该有一个碧桂园建造者类，里边有建地板，墙壁和屋顶共三个方法， 有一个中铁类，也有建地板，墙壁和屋顶共三个方法
   4. 
   5. 那么很自然地就可以想到把方法和IHourse和方法抽出来，放到一个公共的父类中去
   6. 
   7. 于是类图就成了这样子
   8. 
2. 当要建造一个房子的时候，客户端应该new 一个 具体的建造者，就可以了，调用器build方法就可以了
3. 但是这样子有问题，如果有的用户暂时并不需要建造地板，那么就需要到具体的实现类里去增加甚至修改build方法，这么做是违背单一职责原则和开闭原则的
   1. 我们要调整的仅仅是建造的顺序，当时类中存在着具体的建造，调整顺序不能影响具体的建造
   2. 建造者是服务提供方，当客户端需求改变的时候不应该去修改服务方
4. 这时候需要先思考一个问题，具体的建造者目前负责了哪些职责呢？
   1. 房子从无到有的职责
   2. 具体各个建造步骤的职责
   3. 将各个建造步骤进行组合的职责
5. 将这些职责组合合在一个类中是正确的吗？应该不是，违背了单一职责原则，应该有其他类来负责从无到有的职责，有其他了负责各个建造步骤的组合，而建造者类的职责仅仅是建造需要的各个步骤而已
6. 这时可以考虑将从无到有这个职责放到抽象建造者中去，因为在进行具体的建造步骤之前，肯定是有将房子从无到有的，这时所有具体建造者的共性，抽取到抽象建造者中去是合理的
7. 但具体的建造步骤就不是所有的类共有的了，因此需要有一种类，负责组合各个建造步骤，这就是指挥者，指挥者也有接口，底下是各个具体的指挥者类，可以对建造者中各个建造步骤进行组合（不仅仅是顺序，也可以去掉其中的某些步骤，或者添加某些额外的步骤）
8. 这样子的话，客户端就不是使用建造者的build方法了，而是调指挥者的方法了
9. 重点：
   1. 抽象建造者负责从无到有的职责
   2. 具体建造者负责实现具体的建造步骤
   3. 指挥者负责组合各个建造步骤
10. 类图
    1. 
    2.