建造者模式，你学废了吗？

弟弟懊恼地走了过来，说：建造者模式是个啥玩意？搞不懂！搞不懂！

我会心一笑，秒懂他在想什么。于是说道：你在网上看到的博客是不是都是将建造者模式的标准模型：建造者抽象类，实际创建者，管理者。或者是简化一下，把管理者的权限交给使用者来实现建造顺序的控制？

弟弟点头称是。

我接着说道：有没有人扔给你一句莫名奇妙的话《将一个复杂对象的构建与其表示分离，使得同样的构建过程可以创建不同的表示》？

弟弟：这些字我都认识，连一块就不知道啥意思了？你到底会不会，别跟我扯淡！

我轻哼一声：要说明白这个建造者模式，那就不得不说它的应用场景了。来来来，还是举个栗子说吧！

开始装13：炒菜有一些场景，分别是

动作一：加水；动作二：加油；动作三：加盐；动作四：加糖。
最后还要贴上标签，让人知道这是什么菜，避免混淆，图来！！！

1. 皇上：我要吃张三做的第一种填的佛跳墙！
2. 厨师长接到信息，顺手出了一个单子：《第一种佛跳墙：来碗带糖佛跳墙；贴标签。》，转手就把单子扔给了张三。
3. 厨子张三按照厨师长的单子，把菜做出来交给厨师长；
4. 厨师长把菜给皇帝送上来。

弟弟：这绕来绕去有啥用？

我：一个人来吃饭当然看不出来优势，但是人多了之后，没有厨师长在这里强行控制，直接做菜（给菜设定属性）则有遗忘的危险，比如忘加标签了，菜虽然做出来了，但是忘了是啥菜、不能够端上桌了。这里属性比较单一，当对象的属性多了之后直接创建实例时赋值就会显得复杂，很容易漏掉一些属性。
这里有组团出道的意思，每种口味的菜，把要设置的不同属性捆绑在一起。便于控制细节上的风险。

其次：我们还可以把多个set方法封装到厨师的一个工序中，这样用户不必知道菜内部的细节就行，只要知道操作了这道工序就行了。

最后：厨师是独立的，容易扩展，只要让厨师会菜谱就行了（实现抽象类）

弟弟：so easy！原来就是创建个带点属性的实例，我还是使用工厂模式搞定吧！创建者模式不写也罢！
我心里暗道：我愚蠢的弟弟呦！嘴上却说：这两种模式确实有相似之处，但是工厂模式注重的是把菜炒出来，只要是这种菜就行，；而建造者模式注重的是细节的雕琢，就如同佛跳墙，添个雕刻摆件增加艺术气息，撒点干冰营造烟雾飘渺之感，盘子上写点书法提升文化内涵等
总结一下就是：工厂模式着重在同系列实例整体的创建，而假造者模式注重在创建一种对象实例时对细节的把控。

弟弟：原来是这样啊！需要蒸羊羔、蒸熊掌、蒸鹿尾儿、烧花鸭…实例就工厂，需要特定的酸需要特定的酸蒸羊羔、甜蒸羊羔、苦蒸羊羔、辣蒸羊羔…就建造者模式！

我：斗嘴强者，恐怖如斯！！！

github代码