淺學設計模式之建造者（Buildler Pattern）模式及在android中的應用
被自己用一根香蕉收買後，舒舒服服的洗完澡以後，認認真真的做完50多個仰臥起坐以後，在得到自己想要的訊息後，好吧，不管是無意或者有意。好吧，現在就將近12點了，關於建造者模式，是今天自己再看劉偉老師的設計模式PPT的時候學習的，在《Head First 設計模式》那本書裡是沒有講這個建造者模式，好吧，再一次說明，關於設計模式系列文章的文字部分大部分是從網上整理而來，程式碼部分由自己完成，因為自我感覺還沒有能力能夠系統的解釋一個模式，已經有現成的比較完善的說明，就不重複造輪子了。
一、概述：
在軟體系統中，有時候面臨著“一個複雜物件”的建立工作，其通常由各個部分的子物件用一定的演算法構成；由於需求的變化，這個複雜物件的各個部分經常面臨著劇烈的變化，但是將它們組合在一起的演算法確相對穩定。如何應對這種變化？如何提供一種“封裝機制”來隔離出“複雜物件的各個部分”的變化，從而保持系統中的 “穩定構建演算法”不隨著需求改變而改變？這就是要說的建造者模式。
二、定義：
建造者模式（Builder Pattern）也叫生成器模式，其定義如下：
separate the construction of a complex object from its representation so that the same construction process can create different representations.將一個複雜物件的構建與它的標示分離，使同樣的構建過程刻意建立不同的表示。
三、類圖：
- 建造者（Builder）角色：給出一個抽象介面，以規範產品物件的各個組成成分的建造。一般而言，此介面獨立於應用程式的商業邏輯。模式中直接建立產品物件的是具體建造者（Concrete Builder）角色。具體建造者類必須實現這個介面所要求的方法：一個是建造方法，另一個是結果返還方法。
- 具體建造者（Concrete Builder）角色：擔任這個角色的是於應用程式緊密相關的類，它們在應用程式呼叫下建立產品例項。這個角色主要完成的任務包括：實現Builder角色提供的介面，一步一步完成建立產品例項的過程。在建造過程完成後，提供產品的例項。
- 指導者（Director）角色：擔任這個角色的類呼叫具體建造者角色以建立產品物件。導演者並沒有產品類的具體知識，真正擁有產品類的具體知識的是具體建造者物件。
- 產品（Product）角色：產品便是建造中的複雜物件。指導者角色是於客戶端打交道的角色。導演者角色將客戶端建立產品的請求劃分為對各個零件的建造請求，再將這些請求委派給具體建造者角色。具體建造者角色是做具體建造工作的，但卻不為客戶端所知。
四、程式碼示例
以食物為例，感覺著例子寫的不好，湊合著看下：
先看Product：
public class Food {
private String mFoodName;
private String mFoodTastes;
private String mFoodFeatures;
private String mChillies;
private String mSugar;
private String mSalt;
public void setFoodName(String name) {
mFoodName = name;
}
public String getFoodName() {
return mFoodName;
}
public void setFoodTastes(String tastes) {
mFoodTastes = tastes;
}
public String getFoodTastes() {
return mFoodTastes;
}
public void setFoodFeatures(String features) {
mFoodFeatures = features;
}
public String getFoodFeatures() {
return mFoodFeatures;
}
public String getChillies() {
return mChillies;
}
public void setChillies(String mChillies) {
this.mChillies = mChillies;
}
public String getSugar() {
return mSugar;
}
public void setSugar(String mSugar) {
this.mSugar = mSugar;
}
public String getSalt() {
return mSalt;
}
public void setSalt(String salt) {
mSalt = salt;
}
@Override
public String toString() {
return "Food Name: " + getFoodName() + "\r\n"
+ "Food Feature: " + getFoodFeatures() + "\r\n"
+ "Food Tastes: " + getFoodTastes() + "\r\n"
+ "Food Chillies: " + getChillies() + "\r\n"
+ "Food Salt: " + getSalt() + "\r\n"
+ "Food Sugar: " + getSugar();
}
}上面菜餚中各種屬性，比較簡單，就是一個實體類。
下面是Builder：
public abstract class Builder {
protected Food mFood = new Food();
public abstract void setFoodName(String name);
public abstract void setFoodTastes(String tastes);
public abstract void setFoodFeature(String feature);
public abstract void addSugar(String sugar);
public abstract void addSalt(String salt);
public abstract void addChillies(String chillies);
public Food getResult() {
return mFood;
}
}實體Builder：
public class ShandongCuisineChefBuilder extends Builder{
@Override
public void setFoodName(String name) {
mFood.setFoodName(name);
}
@Override
public void setFoodTastes(String tastes) {
mFood.setFoodTastes(tastes);
}
@Override
public void setFoodFeature(String feature) {
mFood.setFoodFeatures(feature);
}
@Override
public void addSugar(String sugar) {
mFood.setSugar(sugar);
}
@Override
public void addSalt(String salt) {
mFood.setSalt(salt);
}
@Override
public void addChillies(String chilies) {
mFood.setChillies(chilies);
}
}public class SiChuanChefBuilder extends Builder {
@Override
public void setFoodName(String name) {
mFood.setFoodName(name);
}
@Override
public void setFoodTastes(String tastes) {
mFood.setFoodTastes(tastes);
}
@Override
public void setFoodFeature(String feature) {
mFood.setFoodFeatures(feature);
}
@Override
public void addSugar(String sugar) {
mFood.setSugar(sugar);
}
@Override
public void addSalt(String salt) {
mFood.setSalt(salt);
}
@Override
public void addChillies(String chilies) {
mFood.setChillies(chilies);
}
}
這兩個大廚類寫的有點多餘，因為實現完全一樣。
director類：
public class Director {
private Builder mBuilder;
public Director(){}
public Director(Builder builder) {
mBuilder = builder;
}
public void setDirector(Builder builder) {
mBuilder = builder;
}
public Food construct(String name, String feature, String tastes,
String chillies, String salt, String sugar) {
mBuilder.setFoodName(name);
mBuilder.setFoodFeature(feature);
mBuilder.setFoodTastes(tastes);
mBuilder.addChillies(chillies);
mBuilder.addSalt(salt);
mBuilder.addSugar(sugar);
return mBuilder.getResult();
}
}
client類：
public class Client {
/**
* @param args
*/
public static void main(String[] args) {
Builder shandongCuisineChef = new ShandongCuisineChefBuilder();
Builder siChuanChef = new SiChuanChefBuilder();
Director director = new Director(shandongCuisineChef);
Food food = director.construct("糖醋里脊", "色淡黃,形光潤飽滿.外鬆脆酥香,裡軟嫩鮮美", "又甜又香", "無", "適量", "加糖");
System.out.println("經典魯菜： " + "\r\n" + food);
Director director2 = new Director();
director2.setDirector(siChuanChef);
Food food2 = director2.construct("水煮肉片", "肉味香辣，軟嫩，易嚼", "麻、辣、鮮、燙", "多", "適量", "無");
System.out.println("經典川菜： " + "\r\n" + food2);
}
}
程式執行結果：
經典魯菜：
Food Name: 糖醋里脊
Food Feature: 色淡黃,形光潤飽滿.外鬆脆酥香,裡軟嫩鮮美
Food Tastes: 又甜又香
Food Chillies: 無
Food Salt: 適量
Food Sugar: 加糖
經典川菜：
Food Name: 水煮肉片
Food Feature: 肉味香辣，軟嫩，易嚼還算比較簡單，不做過多解釋了。
五、應用
1. 建造者模式的優點
- 封裝性
使用建造者模式可以使客戶端不必知道產品內部組成的細節，如例子中我們就不需要關心每一個具體的模型內部是如何實現的，產生的物件型別就是CarModel。
- 建造者獨立，容易擴充套件
Builder之間是相互獨立的，與其它的Builder無關，對系統的擴充套件非常有利。
- 便於控制細節風險
模式所建造的最終產品更易於控制：由於具體的建造者是獨立的，因此可以對建造過程逐步細化，而不對其他的模組產生任何影響。
2. 建造者模式的使用場景
- 相同的方法，不同的執行順序，產生不同的事件結果時，可以採用建造者模式，需要生成的產品物件的屬性相互依賴，建造者模式可以強迫生成順序。
- 多個部件或零件,都可以裝配到一個物件中，但是產生的執行結果又不相同時，則可以使用該模式。
- 產品類非常複雜，或者產品類中的呼叫順序不同產生了不同的效能，這個時候使用建造者模式是非常合適。
- 在物件建立過程中會使用到系統中的一些其它物件，這些物件在產品物件的建立過程中不易得到時，也可以採用建造者模式封裝該物件的建立過程。該種場景，只能是一個補償方法，因為一個物件不容易獲得，而在設計階段竟然沒有發覺，而要通過建立者模式柔化建立過程，本身已經違反設計最初目標。
3. 建造者模式的注意事項
建造者模式關注的是的零件型別和裝配工藝（順序），這是它與工廠方法模式最大不同的地方，雖然同為建立類模式，但是注重點不同。
六、和其他模式的區別：
- 與抽象工廠模式相比，建造者模式返回一個組裝好的完整產品，而抽象工廠模式返回一系列相關的產品，這些產品位於不同的產品等級結構，構成了一個產品族。
- 在抽象工廠模式中，客戶端例項化工廠類，然後呼叫工廠方法獲取所需產品物件，而在建造者模式中，客戶端可以不直接呼叫建造者的相關方法，而是通過指揮者類來指導如何生成物件，包括物件的組裝過程和建造步驟，它側重於一步步構造一個複雜物件，返回一個完整的物件。
- 如果將抽象工廠模式看成汽車配件生產工廠，生產一個產品族的產品，那麼建造者模式就是一個汽車組裝工廠，通過對部件的組裝可以返回一輛完整的汽車。
七、在android中的應用
Dialog：Dialog的建造過程就是一個典型的“建造者模式”，通過Builder來設定不同的引數，建立出不同的Dialog。好吧，下一篇文章分析Dialog和Builder的原始碼。
相關文章
- JAVA設計模式之 建造者模式【Builder Pattern】Java設計模式UI
- 設計模式--建造者模式(Builder Pattern)設計模式UI
- 重識設計模式-建造者模式（Builder Pattern）設計模式UI
- C#設計模式-建造者模式（Builder Pattern）C#設計模式UI
- 設計模式：建造者模式及在jdk中的體現，建造者模式和工廠模式區別設計模式JDK
- android常用設計模式之建造者設計模式Android設計模式
- 設計模式之建造者模式設計模式
- 設計模式之【建造者模式】設計模式
- 建造者模式(Builder Pattern)模式UI
- golang設計模式之建造者模式Golang設計模式
- JAVA設計模式之建造者模式Java設計模式
- 設計模式系列之「建造者模式」設計模式
- 設計模式之-建造者模式-Builder設計模式UI
- 設計模式學習-建造者模式設計模式
- 設計模式之建造者模式(BuilderPattern)設計模式UI
- Java設計模式之（三）——建造者模式Java設計模式
- 23種設計模式之--建造者模式設計模式
- 23種設計模式之建造者模式設計模式
- Java設計模式之建造者模式（Builder）Java設計模式UI
- 設計模式系列之建造者模式(Builder Pattern)——複雜物件的組裝與建立設計模式UI物件
- 設計模式-建造者模式設計模式
- 設計模式 --建造者模式設計模式
- 設計模式----建造者模式設計模式
- 設計模式 —— 建造者模式設計模式
- 設計模式（建造者模式）設計模式
- 設計模式 | 建造者模式設計模式
- 設計模式之觀察者模式（Observer Pattern）設計模式Server
- 我學設計模式 之 建造模式設計模式
- 設計模式 --建類神器之建造者模式設計模式
- 折騰Java設計模式之建造者模式Java設計模式
- 嘻哈說：設計模式之建造者模式設計模式
- 我所理解的設計模式（C++實現）——建造者模式（Builder Pattern）設計模式C++UI
- 設計模式快速學習（四）建造者模式設計模式
- 設計模式之委派模式（Delegate Pattern）深入淺出設計模式
- JAVA設計模式之 中介者模式【Mediator Pattern】Java設計模式
- java設計模式-建造者模式Java設計模式
- 設計模式（六）——建造者模式設計模式
- 設計模式（十六）：建造者模式設計模式