建造者模式的基本角色,rust建造者模式
家家有本难念的经，人人都有本难念的经。在城市里，人们都在为生存而奔波，每个人都有自己的追求。也许他们以后能有更好的生活，也许他们能在城市里买套房子，成家立业，逃脱被城市边缘化的命运。于是有的人选择奋斗，有的人选择回忆，一个向前看，一个停留在过去向前看，决心已定。当ta在前进的时候，一些在后退的人在感慨：如果我有一个像他一样清晰的人生规划，会怎么样.是的，如果别人的路径可以复制，那么说每个人都是独一无二的就错了。成功的方法千奇百怪，千变万化，没有固定的模式。追求自己的人生，走好自己的路。但是，每个人的人生变化都是一样的，谁也无法逃避。有人说每个人都是公平的，因为生不带来，死不带来，每个人的生死都是固定的，所以可以用一个固定的模式来概括人生：从生到死的演变。
每个人都经历生死，这是固定的。所以在程序世界里，可以用一个类来构建这个固定的进程。因为它是常量，所以我们可以封装这个过程，当我们使用它时，一个类直接负责构建它。例如，在JDBC，通常有几个固定的步骤：
1.Class.forName(驱动程序)；
2.connection conn=driver manager . getconnection(URL，用户名，密码)；
//设置预编译
字符串sql
3.PreparedStatementpstm=conn . prepare statement(SQL)；
那么，既然是一个不断的过程，是否可以考虑封装这三个过程呢？从另一个角度来看，这三个步骤分别由一个单独的班级负责。那么这个时候就有一个指挥者指挥这三个班一起合作，提供一个稳定的构建过程，得到我们需要的产品。
如何堆雪人每个人都很清楚。无非是身体——左手——右手——头——眼睛——鼻子——耳朵——嘴巴。因为难，所以容易退缩。我们发现这个过程是固定的。当然也有人说我能让它改变，因为我没有鼻子，所以这是个错误。我们希望一个雪人是成品，缺少耳朵和鼻子的雪人是残次品，不符合我们的需求。其实大家在搭建的时候，难免会忽略一些东西，因为每个人的技巧和考量都不一样。如果今天同一个人激动了，最后漏嘴了，或者心情不好，干脆左手不要了，这样的雪人是不合格的。犯这个错误是违背原则的，那就是
倒置原则——抽象不应该依赖于细节，细节应该依赖于抽象。在这里，如果雪人依赖于每一个人，就相当于依赖于每一个具体的人。耦合度高，雪人缺胳膊少退是必然的(这里默认没有退)。
解决方法：将这个固定的过程提取出来打包，然后要创建这个雪人，就必须按照这些步骤来，这样才能避免不完整的现象。
于是，建造者模式登场了：
把一个复杂对象的构造和它的表示分开，这样同一个构造过程可以创建不同的表示。
具体的雪人建造者，高的矮的：HighSnowmanBuilder，LowSnowmanBuilder，都继承了抽象的雪人建造者，有稳定的建造过程。
C.类的交互：Direct commander，依赖抽象的雪人构建器类，负责调用构建器的构建过程。客户只需要和指挥官沟通，告诉他我想要一个雪人。
}
@为具体的构建者提供了一个稳定的抽象构建行为来实现这些行为，每个行为都是构建的一个表征。
HighSnowmanBuiler:
/**
*高个雪人建造者类
* @作者PingCX
公共类HighSnowmanBuilder扩展SnowmanBuilder {
@覆盖
public void buildBody() {
雪人. add(高个雪人身材，身高195cm);
@覆盖
public void buildLeftArm() {
雪人. add(高个子雪人的左臂有70厘米长……));
@覆盖
public void buildRightArm() {
Snowman.add(高个雪人的右臂，70cm长.);
@覆盖
public void buildHead() {
雪人. add(高高的雪人头.);
@覆盖
公共雪人getSnowman() {
还雪人；
}
LowSnowmanBuilder:
/**
*短雪人生成器类
* @作者PingCX
公共类LowSnowmanBuilder扩展SnowmanBuilder {
@覆盖
public void buildBody() {
雪人. add(雪人身材矮小，身高155cm);
@覆盖
public void buildLeftArm() {
雪人. add(矮雪人的左臂有55cm长.);
@覆盖
public void buildRightArm() {
雪人. add(雪人右臂短，55cm长.);
@覆盖
public void buildHead() {
雪人. add(矮雪人头.);
@覆盖
公共雪人getSnowman() {
还雪人；
}
重要角色出道：
}
@这个commander里面有一个抽象的build，提供了一个创建雪人的接口。可以理解为，这个指挥者指挥这个建造者去建造，指挥者把创造过程和它的表象分离开来，让同一个创造过程创造出不同表象的产品。即使建造者心不在焉，也有我的指挥官。当然，指挥官不能心不在焉。为什么不呢？就看具体指挥者如何实现抽象指挥者的这种创造行为：
}
@在createSnowman的具体实现中，构建器的构建过程是一个一个调用的，这里依赖的是抽象的构建器。至于为什么指挥官不能开小差，我觉得很明显，因为整个构建过程都要完成，如果在实现中忘记调用某个方法，就会得到一个残次品，所以领导要比下属付出更多的责任，否则你作为领导的工资就不是白付的。
公共静态void main(String[] args) {
HighSnowmanBuilder hBuilder=new HighSnowmanBuilder()；
导演ysjian=新ys Jian(hBuilder)；
ysjian . createsnowman()；
雪人snowman=hbuilder . get snowman()；
snowman . show()；
system . out . println(-)；
lownesmanbuilder lBuilder=new lownesmanbuilder()；
导演ysjian2=新ys Jian(l builder)；
ysjian 2 . createsnowman()；
雪人snowman 2=lbuilder . get snowman()；
snowman 2 . show()；
}
@顾客告诉指挥官，我想要一个高个的雪人。这是指挥官告诉高个子雪人建造者的。你可以快速给我建一个，然后一步一步的创建。当然，顾客不需要知道这种创造的细节。用户只需要他的产品，所以耦合度大大降低。
总结：关注的人会注意到，上面已经说了，提供了一个稳定的构建过程，要构建的对象的内部实现是不同的。
因此，构建器模型用于构建过程稳定但内部通常面临复杂变化的对象。因为产品构建过程是稳定的，如果我们需要一个胖雪人，只需要写一个继承自抽象构建器类的新类，然后在具体实现中写相应的代码，扩展性很强。
当一个对象的算法应该独立于对象的组件以及它们是如何组装的时候，可以考虑构建器模式。
结尾：向前看，不要沉湎于过去，用自己的努力去打造属于自己的生活。也许我们无法逃避生老病死，坦然面对。至少到了人生的尽头，我们没有太多的遗憾。我们付出了，也收获了。
郑重声明：本文由网友发布，不代表盛行IT的观点，版权归原作者所有，仅为传播更多信息之目的，如有侵权请联系，我们将第一时间修改或删除，多谢。