建造者模式,你学废了吗?

655 阅读3分钟

弟弟懊恼地走了过来,说:建造者模式是个啥玩意?搞不懂!搞不懂!

懊恼1.jpg

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

弟弟点头称是。

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

弟弟:这些字我都认识,连一块就不知道啥意思了?你到底会不会,别跟我扯淡!

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

不屑1.jpg

开始装13:炒菜有一些场景,分别是

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

建造者模式.jpg

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

弟弟:这绕来绕去有啥用?

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

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

最后:厨师是独立的,容易扩展,只要让厨师会菜谱就行了(实现抽象类)

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

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

得意1.jpg

我:斗嘴强者,恐怖如斯!!!

目瞪狗呆1.jpg

github代码