建造者模式
建造者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)點(diǎn)：
- 在建造者模式中，客戶端不必知道產(chǎn)品內(nèi)部組成的細(xì)節(jié)，將產(chǎn)品本身與產(chǎn)品的創(chuàng)建過程解 耦，使得相同的創(chuàng)建過程可以創(chuàng)建不同的產(chǎn)品對象。
- 每一個具體建造者都相對獨(dú)立，而與其他的具體建造者無關(guān)，因此可以很方便地替換具體 建造者或增加新的具體建造者，用戶使用不同的具體建造者即可得到不同的產(chǎn)品對象。由于 指揮者類針對抽象建造者編程，增加新的具體建造者無須修改原有類庫的代碼，系統(tǒng)擴(kuò)展方 便，符合“開閉原則”
- 可以更加精細(xì)地控制產(chǎn)品的創(chuàng)建過程。將復(fù)雜產(chǎn)品的創(chuàng)建步驟分解在不同的方法中，使得 創(chuàng)建過程更加清晰，也更方便使用程序來控制創(chuàng)建過程。
缺點(diǎn)
- 建造者模式所創(chuàng)建的產(chǎn)品一般具有較多的共同點(diǎn)，其組成部分相似，如果產(chǎn)品之間的差異 性很大，例如很多組成部分都不相同，不適合使用建造者模式，因此其使用范圍受到一定的 限制。
- 如果產(chǎn)品的內(nèi)部變化復(fù)雜，可能會導(dǎo)致需要定義很多具體建造者類來實(shí)現(xiàn)這種變化，導(dǎo)致 系統(tǒng)變得很龐大，增加系統(tǒng)的理解難度和運(yùn)行成本。
