设计模式之构建(Builder)模式 建造房子实例分析
构建模式主要用来针对复杂产品生产,分离部件构建细节,以达到良好的伸缩性。
考虑到设计模式来源于建筑学,因此举一个建造房子的例子。现在一个客户要建造一栋房子House,
代码如下:
public class House{
//客户需求的房子
}
那么他首先需要一个设计师—Designer,但是设计师只能做设计,指示如何去建造房子,可是他并不会亲自去做,那么就还需要一个施工队伍BuildTeam,那么首先,Designer要设计出来如何去建造这栋房子,首先要施工队打地基,然后施工队要架骨架、接着上水泥等等(具体如何不得而知,需要请教专业人士),那么从这里我们可以知道设计师对施工队是有要求的,那就是施工队必须要会打地基、会架骨架、会上水泥等,因此得出如下招聘施工队的要求:
代码如下:
public interface BuildTeam{
public void 打地基();
public void 架骨架();
public void 上水泥();
。。。。。。
}
从上可以看出,要想做这个工程的施工队伍,必须首先符号上面的条件,会做上面所有的事情。根据设计师的设计,又得知设计师会向施工队下达一个命令,然后施工队按照设计师的要求开始施工:
代码如下:
public class Designer{
public void construct(BuildTeam team){
team.打地基();
team.架骨架();
team.上水泥();
}
}
由于从头到尾都是设计师在下指令设计,而施工队进行实际施工,所以客户最终会找施工队验收房子,因此施工队必须要交付房子给客户,因此施工队需要加上一个交付房子的条款,不然房子做成了,但是施工队却不交付给我,那不是吃亏了,因此:
代码如下:
public interface BuildTeam{
public void 打地基();
public void 架骨架();
public void 上水泥();
。。。。。。
public House deliverHouse(); //增加一个交付房子的方法。
}
好了,房子设计好了,如何做也设计好了,如今就差给谁来做了,现在有一个施工队:
代码如下:
public class BuildTeamA extends BuildTeam{
public void 打地基(){}
public void 架骨架(){}
public void 上水泥(){}
。。。。。。
public House deliverHouse(){}
}
从施工队的情况来看, 这个施工队完全符合设计师对施工队的要求,既接口BuildTeam,好,那么最终决定由他们来做,从头到尾全部流程如下:
Designer designer = new Designer(); //找到一个设计师
BuildTeam teamA = new BuildTeamA(); //找到一个施工队伍BuildTeamA
designer.construct(teamA); //设计师下命令,让施工队伍按照他的设计开始建造
House house = teamA.deliverHouse(); //施工队完成后交付房子
第一栋房子终于建成了,此时同一个客户觉得这个设计师的设计不错,于是决定还要使用他的设计并由他指示施工队再造一栋同样的房子,可是施工队BuildTeamA突然狮子大开口,想要更多的钱,客户为了节省成本,只好再次招聘一个新的施工队进行施工,刚好有个施工队伍BuildTeamB符合要求,于是流程如下:
代码如下:
BuildTeam teamB = new BuildTeamB();
designer.construct(teamB); //由于设计师没变,且造同样的房子,所以designer不需要重新找,只需要把他指示的施工队换成BuildTeamB即可
House house = teamB.deliverHouse(); //施工队完成后交付房子
好了,第二栋房子也完成了,但是整个流程上并没有太大的变动,由于使用了构建模式,整个流程分工非常明确,客户不需要参与任何设计以及建造,设计师只负责设计以及下命令,而施工队也仅仅只负责具体的实现细节,使得建造明细独立出来,随时更换不同的施工队均可。