一、特点
解决了什么问题，为什么其它模式不行
对比工厂模式
- 都屏蔽了目标对象点创建细节
- 工厂生产的对象大多是一样的，说白了对于工厂中的对象属性都是同一个，建造用来建造那些不同的。
二、模式结构
产品Product
》包含多个组成部件的复杂对象抽象建造者IBuilder
》包含创建产品各个子部件的抽象方法的接口
》通常还包含一个返回复杂产品的方法具体建造者Builder
》完成复杂产品的各个子部件的具体创建方法指挥者Director
》调用建造者对象中的部件构造与装配方法完成复杂对象的创建三、使用场景
场景一
创建复杂对象，其产品的各个部分经常面临着剧烈的变化，但将它们组合在一起的算法却相对稳定。
创建一个对象P其包含了ABCD等多个元素理解一
某个子部件产生变种：A=>A1理解二
去掉子部件中的一个或多个：ABC理解三
新增一个子部件：ABCDE。当然这个可以当做是理解二的扩展总结
如果是前者则需要创建不同的具体建造者，如果是后者通过不同的指挥者好像更合适。
也有可能后者理解有误，前者才是传统意义的建造者模式。带来的好处
可以创建多种多样的产品使用要求
产品必须有共同点
也可以理解为多个子部件能构成一个并集且其交集约等于并集，要求的建造者包含并集的创建场景二
创建复杂对象，子部件的创建不变动，但构建产品的方式有变动。理解一
少构建一个子部件，某种意义上就是场景一的理解二。理解二
仅变更组配顺序也会影响最终的产品：ABCD<>ADBC四、应用
构建流程相同型
游戏角色，其性别、个性、能力、脸型、体型、服装、发型等特性都有所差异
汽车中的方向盘、发动机、车架、轮胎等部件也多种多样
每封电子邮件的发件人、收件人、主题、内容、附件等内容也各不相同个人理解
若采用不同的具体构建者，看上去也不怎么合适。
因此进一步说明场景二更适合使用建造者模式不同组合型
肯德基，汉堡、可乐、薯条、炸鸡翅等是不变的，而其组合是经常变化的，生成出所谓的”套餐”五、网上的一些观点
当一个类的构造函数参数个数超过4个，而且这些参数有些是可选的参数，考虑使用构造者模式。
https://zhuanlan.zhihu.com/p/58093669
若有收获，就点个赞吧
0 人点赞
