1. 定義：
將一個復(fù)雜對象的構(gòu)建與它的表示分離，使得同樣的構(gòu)建過程可以創(chuàng)建不同的表示况鸣。生成器模式利用一個導(dǎo)演者對象和具體建造者對象一個一個地建造出所有的零件磁餐，從而建造出完整的對象子漩。
2. 四個要素：
- Builder：生成器接口，定義創(chuàng)建一個Product對象所需要的各個部件的操作舆蝴。
- ConcreteBuilder：具體的生成器實現(xiàn)谦絮，實現(xiàn)各個部件的創(chuàng)建，并負責(zé)組裝Product對象的各個部件洁仗，同時還提供一個讓用戶獲取組裝完成后的產(chǎn)品對象的方法层皱。
- Director：指導(dǎo)者，也被稱導(dǎo)向者赠潦，主要用來使用Builder接口叫胖，以一個統(tǒng)一的過程來構(gòu)建所需要的Product對象。
- Product：產(chǎn)品祭椰，表示被生成器構(gòu)建的復(fù)雜對象臭家，包含多個部件。
3. 示例：
網(wǎng)上有用KFC的例子來描述生成器模式方淤，比較通俗易懂钉赁。
假設(shè)KFC推出兩種套餐：奧爾良雞腿堡套餐 和 香辣雞腿堡套餐。
- 奧爾良套餐包括：一個奧爾良雞腿堡携茂、一個炸雞翅你踩、一杯雪碧。
- 雞腿堡套餐包括：一個香辣雞腿堡讳苦、一份薯條带膜、一杯可樂。
每份套餐都是：主食鸳谜、副食膝藕、飲料。
KFC服務(wù)員要根據(jù)顧客的要求來提供套餐咐扭，那這個需求里面什么是固定的芭挽，什么是變化的呢滑废？很明顯顧客都是要的套餐，顧客的目的是一樣的袜爪。 套餐里面都是主食蠕趁、副食、飲料辛馆，這也是固定的俺陋。至于主食是什么、副食是什么昙篙、飲料是什么腊状，這個是變化的。
在實際的軟件開發(fā)過程中瓢对，有時候面臨著“一個復(fù)雜對象”的創(chuàng)建工作寿酌，其通常由各個部分的子對象采用一定的組合構(gòu)成胰苏，由于需求的變化硕蛹，這個復(fù)雜對象的各個部分或者其子對象經(jīng)常要變化（例如，雞腿堡套餐的顧客不喜歡可樂硕并，要換奶茶）法焰，但是他們的結(jié)構(gòu)卻相對穩(wěn)定（套餐都得是一份主食，副食及飲料）倔毙。當(dāng)遇到這種場景時埃仪，使用生成器模式比較合適。
3.1 定義一個產(chǎn)品類
public class Entity1{...}
public class Entity2{...}
public class Entity3{...}
public class Product{
Entity1 entity1;
Entity2 entity2;
Entity3 entity3;
}
產(chǎn)品類中的各個小模塊是不一樣的陕赃，由他們建造組成產(chǎn)品卵蛉。
3.2 根據(jù)具體場景要求，定義n個生成器類：
public interface IBuild{
public void createEntity1();
public void createEntity2();
public void createEntity3();
public Product composite();
public Product create();
}
public class BuildProduct implements IBuild{
Product p = new Product();
public void createEntity1(){
//p.entity1 = ...
}
public Product create(){
return composite();
}
......
}
public class BuildProduct1 implements IBuild{
Product p = new Product();
public void createEntity1(){
//p.entity1 = ...
}
......
}
3.3 定義一個指揮者類么库，統(tǒng)一調(diào)度project：
public class Director{
private IBuild build;
public Director(IBuild build){
this.build = buid;
}
public Product build(){
build.create();
}
public static void main(){
IBuild build = new BuildProduct();
Director direcotr = new Director(build);
Prodcut p = director.build();
}
}
3. 優(yōu)點：
- 使用生成器模式可以使客戶端不必知道產(chǎn)品內(nèi)部組成的細節(jié)傻丝。
- 具體的建造者類之間是相互獨立的，對系統(tǒng)的擴展非常有利诉儒。
- 由于具體的建造者是獨立的葡缰，因此可以對建造過程逐步細化，而不對其他的模塊產(chǎn)生任何影響忱反。
4. 缺點：
建造者模式的“加工工藝”是暴露的泛释，這樣使得建造者模式更加靈活，也使得工藝變得對客戶不透明温算。（待考證怜校，筆者這里不是很理解，歡迎說自己的見解）
5. 應(yīng)用場景：
- 需要生成一個產(chǎn)品對象有復(fù)雜的內(nèi)部結(jié)構(gòu)注竿。每一個內(nèi)部成分本身可以是對象茄茁，也可以使一個對象的一個組成部分宇智。
- 需要生成的產(chǎn)品對象的屬性相互依賴。建造模式可以強制實行一種分步驟進行的建造過程胰丁。
- 在對象創(chuàng)建過程中會使用到系統(tǒng)中的其他一些對象随橘，這些對象在產(chǎn)品對象的創(chuàng)建過程中不易得到
