構建模式主要用來針對復雜產品生產，分離部件構建細節，以達到良好的伸縮性。
考慮到設計模式來源於建築學，因此舉一個建造房子的例子。現在一個客戶要建造一棟房子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(); //施工隊完成後交付房子
好了，第二棟房子也完成了，但是整個流程上並沒有太大的變動，由於使用了構建模式，整個流程分工非常明確，客戶不需要參與任何設計以及建造，設計師只負責設計以及下命令，而施工隊也僅僅只負責具體的實現細節，使得建造明細獨立出來，隨時更換不同的施工隊均可。
