建造者模式是最後一個創建型設計模式，也是研究對象的創建。 將一個複雜對象的創建與它的表示分離，使得同樣的構建過程可以創建不同的表示。 創建和表示是什麼意思 ？ 表示就是外在，對象具體的樣子，而內部構建過程是一種組裝的概念，有點像套娃，同樣的結構，但是卻產生了不同大小的樣子。 按照慣例，先講故事。 假 ...
建造者模式是最後一個創建型設計模式，也是研究對象的創建。
將一個複雜對象的創建與它的表示分離，使得同樣的構建過程可以創建不同的表示。
創建和表示是什麼意思？
表示就是外在，對象具體的樣子，而內部構建過程是一種組裝的概念，有點像套娃，同樣的結構，但是卻產生了不同大小的樣子。
按照慣例，先講故事。
假設要生產一部iPhone和一部ipod。我們要怎麼做？
public class IPhone {
private String camera;
private String touchScreen;
private String communication;
//省略getter，setter方法。public class Ipod {
private String camera;
private String touchScreen;
//省略getter，setter方法。public static void main(String[] args) {
IPhone iPhone = new IPhone();
Ipod ipod = new Ipod();
iPhone.setCamera("1200 pixel");
iPhone.setTouchScreen("retina");
iPhone.setCommunication("TDMA");
ipod.setCamera("800 pixel");
ipod.setTouchScreen("NOVA");
}我們知道同為apple旗艦產品的iPhone和ipod其實差不太多，只是iPhone的配置相對高一些，同時多了通訊模塊。那麼上面的代碼是否顯得臃腫，沒有設計，因為都是在創建對象的時候去設置其屬性，而且這兩款產品的屬性似乎差不多，好像可以套用一樣的生產線。
建造者模式 = buildX() + construct() + (optional)ifX()
第一次建造
增加一個基類Apple產品類，包含並集的所有零件的屬性。
public class Apple {
private String camera;
private String touchScreen;
private String communication;
//省略getter，setter方法。增加一個abstract AppleBuilder類，包含Apple的成員對象。然後加入buildX方法，以及鉤子方法ifX用來判斷某些只有一些子類特有的屬性。最後要加一個成員對象apple的獲取方法。
註意：這個apple對象要定義為protected的原因是它的子類要直接使用這個對象。
public abstract class AppleBuilder {
protected Apple apple = new Apple();
public abstract void buildCamera();
public abstract void buildTouchScreen();
public abstract void buildCommunication();
public boolean ifCommunication() {
return false;
}
public Apple createApple() {
return apple;
}
}然後修改IPhone類和Ipod類，讓他們實現AppleBuild類，可以直接使用基類的apple對象，而不必自身再去定義Apple中已經定義好的屬性們，只需實現AppleBuilder類的abstract funciton buildX們。同時，不要忘記，由於預設ifCommunication是false，所以IPhone類一定要重寫改鉤子方法，修改為return true的方式。
public class IPhone extends AppleBuilder {
@Override
public void buildCamera() {
apple.setCamera("1200 pixel");
}
@Override
public void buildTouchScreen() {
apple.setTouchScreen("retina");
}
@Override
public void buildCommunication() {
apple.setCommunication("TDMA");
}
@Override
public boolean ifCommunication() {
return true;
}
}public class Ipod extends AppleBuilder {
@Override
public void buildCamera() {
apple.setCamera("800 pixel");
}
@Override
public void buildTouchScreen() {
apple.setTouchScreen("NOVA");
}
@Override
public void buildCommunication() {
apple.setCommunication("none");
}
}最後，要加入關鍵的導演類，這裡是車間類，用於真正的組裝工作，對外提供裝配方法construct();
public class Workshop {
public static Apple construct(AppleBuilder ab) {
ab.buildCamera();
ab.buildTouchScreen();
if (ab.ifCommunication()) {
ab.buildCommunication();
}
Apple apple = ab.createApple();
return apple;
}
}這樣，就可以直接在客戶端調用了。
public static void main(String[] args) {
Apple apple = Workshop.construct(new IPhone());
System.out.println("" + apple.getCamera());
}客戶端調用的時候，只需要新建一個workshop對象，然後調用其construct方法，傳入具體的Apple產品子類即可獲得一個Apple類。而new IPhone()我們可以使用配置文件的方式，這裡給出代碼。
public static void main(String[] args) {
Apple apple = Workshop.construct((AppleBuilder) XMLUtil.getBean());
System.out.println("" + apple.getCamera());
}配置文件
<?xml version="1.0"?>
<config>
<className>construction.IPhone</className>
</config> 建立XMLUtil類
public class XMLUtil {
public static Object getBean() {
try {
DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
DocumentBuilder db = dbf.newDocumentBuilder();
Document doc = db.parse(new File("E:\\Evsward\\workspace\\test\\src\\config.xml"));
NodeList nl = doc.getElementsByTagName("className");
Node n = nl.item(0).getFirstChild();
String className = n.getNodeValue();
Object c = Class.forName(className).newInstance();
return c;
} catch (Exception e) {
e.printStackTrace();
}
return null;
}
}
以上就是第一次建造的全部代碼了。我們可以清晰地看到完整的建造者模式的結構。幾個要註意的點是：
- 目前的幾個對象是可以抽象出來一個包含所有屬性的對象，如此例中的Apple類。
- 我們去掉了具體的對象類，而是直接採用Builder的方式，將每個對象具體的內容實現在其裡面。
- Builder要抽象出來一個基類，要包含上面的那個總對象以及該對象的對外獲取方法。同時要註意設置該對象為protected，因為其子類Builder們要直接使用該對象，給該對象的屬性賦值。
- 最重要的導演類，此例中的車間類，只提供一個construct方法，我覺得設置為static更好，外部可以直接通過類來調用。該方法內部要去調用具體的buildX的順序。
第二次建造
這一次建造致力於最大限度精簡化，此次建造屬於探索性建造，不一定用於生產環境。
去掉導演類，將construct方法移入AppleBuilder類中。然後客戶端調用方式為
public static void main(String[] args) {
Apple apple = AppleBuilder.construct((AppleBuilder) XMLUtil.getBean());
System.out.println("" + apple.getCamera());
}這樣雖然精簡結構了，但是會讓代碼變得不可讀，AppleBuilder類的職責太多，不僅要創建對象，提供外部訪問方法，還要聲明各種buildX方法，以及可能出現的鉤子方法，違背了“單一職責原則”。
所以當系統業務比較複雜的時候，不推薦省略導演類，完整的建造者模式會提高代碼的可讀性，以及更好的擴展。
適用場景
- 當要創建的對象內部屬性比較複雜，且與其他對象有公共的部分的時候。
需要生成的對象屬性可以變成buildX的形式，對屬性賦值的順序有要求。
- 隔離複雜對象的創建和使用，並使得相同的創建過程可以創建不同的產品。
創建過程是在導演類中進行，這就與使用隔離開來。
