建造者模式
建造者UML.png
class Goods{
private String A;
private String B;
private String C;
//setter and getter
// toString
}
最終得到的商品類布隔,A丐黄,B,C假想成商品的重要組成部分
abstract class GoodsBuild{
protected Goods goods = new Goods();
public abstract buildA();
public abstract buildB();
public abstract buildC();
public Goods makeGoods(){
return goods;
}
}
抽象建造者
class AGoodsBuild extends GoodsBuild{
public void buildA(){
goods.setA("A商品的第一個屬性");
}
public void buildB(){
goods.setA("A商品的第二個屬性");
}
public void buildC(){
goods.setA("A商品的第三個屬性");
}
}
A商品的構(gòu)造器
class BGoodsBuild extends GoodsBuild{
public void buildA(){
goods.setA("B商品的第一個屬性");
}
public void buildB(){
goods.setA("B商品的第二個屬性");
}
public void buildC(){
goods.setA("B商品的第三個屬性");
}
}
B商品的構(gòu)造器
class GoodsController{
public Goods getGoods(GoodsBuild gb){
gb.buildA();
gb.buildB();
gb.buildC();
return gb.makeGoods();
}
}
商品控制器硕舆,用來拿商品的
class Client{
public static void main(String args[]){
GoodBuild gb = new AGoodsBuild();
GoodsController controller = new GoodsController();
Goods goods = controller.getGoods(gb);
}
}
客戶端,一個商品控制器傳入一個具體的商品構(gòu)造器即可獲得對于屬性的商品goods骤公。
優(yōu)點:
- 在建造者模式中抚官,客戶端不必知道產(chǎn)品內(nèi)部組成的細節(jié),將產(chǎn)品本身與產(chǎn)品的創(chuàng)建過程解 耦阶捆,使得相同的創(chuàng)建過程可以創(chuàng)建不同的產(chǎn)品對象凌节。
- 每一個具體建造者都相對獨立,而與其他的具體建造者無關(guān)洒试,因此可以很方便地替換具體 建造者或增加新的具體建造者刊咳,用戶使用不同的具體建造者即可得到不同的產(chǎn)品對象。由于 指揮者類針對抽象建造者編程儡司,增加新的具體建造者無須修改原有類庫的代碼娱挨,系統(tǒng)擴展方 便,符合“開閉原則”
- 可以更加精細地控制產(chǎn)品的創(chuàng)建過程捕犬。將復(fù)雜產(chǎn)品的創(chuàng)建步驟分解在不同的方法中跷坝,使得 創(chuàng)建過程更加清晰酵镜,也更方便使用程序來控制創(chuàng)建過程。
缺點
- 建造者模式所創(chuàng)建的產(chǎn)品一般具有較多的共同點柴钻,其組成部分相似淮韭,如果產(chǎn)品之間的差異 性很大,例如很多組成部分都不相同贴届,不適合使用建造者模式靠粪,因此其使用范圍受到一定的 限制。
- 如果產(chǎn)品的內(nèi)部變化復(fù)雜毫蚓,可能會導(dǎo)致需要定義很多具體建造者類來實現(xiàn)這種變化占键,導(dǎo)致 系統(tǒng)變得很龐大,增加系統(tǒng)的理解難度和運行成本元潘。