建造者模式，用生活中具体例子来理解建造者思想

概念

将一个复杂的对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。

概念理解

其实我个人最烦的就是上面那种抽象概念，一点用没有，不过我还是写上了哈哈。谈谈个人对建造者模式的理解。
首先，举个例子，比如，你喜欢吃炸酱面，但是你发现，门口的每家炸酱面的做法都不尽相同，每家味道都不一样，因为具体步骤不太相同。但是，反观肯德基，你会发现，无论你去哪个城市的哪家肯德基，味道都一样，这是为什么？就是因为，肯德基的流程步骤是固定的。
再说个场景，如果我们需要一个对象，但是这个对象的属性特别多，有一些是必须的，有一些不是必须的，那我们的构造器怎么写，排列组合吗？如果属性很多呢？100个属性，这要排列组合下来，需要写多少个构造器？或者，写set方法，但是，创建你这个对象的人，他不一定就非常了解其中的所有属性，那他是不是要了解所有属性呢？不然那他就没法创建对象了吗？
举例理解
还举刚才炸酱面的例子，假如我们需要做炸酱面，就需要一个炸酱面的类，里面封装一些属性：
面条（必须）
炸酱（必须）
黄瓜
青菜
萝卜
好了，我们写了炸酱面的对象，里面面条和炸酱是必须的。
现在，我们写一个做炸酱面的抽象类，然后，具体实现包含老北京炸酱面，隔壁面馆的炸酱面。
假如老北京炸酱面需要黄瓜加青菜，隔壁面馆需要黄瓜加萝卜。
按照一般的方式，我们让老北京炸酱面实现抽象方法，然后具体创建的时候，需要new老北京炸酱面的对象，同时把黄瓜和青菜作为参数传入。
分析上述过程，不难发现，new老北京炸酱面的对象，这一步，创建者需要知道老北京炸酱面的具体配方才能点这个菜，这是不是就强人所难了？
而我们日常生活中，都是直接去店里点老北京炸酱面就行了，具体什么配方，我们不需要担心，对吧？
这个例子中，老北京炸酱面就是表示，表示应该与构建分离，因此，我们专门定义一个类：
Director类
就是类似上述的店家，店家就是管理表示的，老北京炸酱面就是表示，Director类就是把表示转化成具体构建步骤，Director类把黄瓜加青菜的配方写好了，然后调用老北京炸酱面的具体实现类，创建出对象，然后返回给Client客户端，就是使用者。
Client客户端
就是上述例子的使用者，只需要给出一个表示给Director类，比如老北京炸酱面，然后Director类直接返回现成的对象。
Builder类
抽象建造者类，此例中，就是炸酱面的总体抽象类。
ConcreteBuilder类
具体抽象类，在此例中，就是老北京炸酱面的具体实现类，被Director类调用，然后传入具体参数后，创建出实例对象。