英文名BUILDER

用於將一個複雜物件與它的表示分離。使得同樣的建立過程可以建立不同的表示。

假設現在要將一個RTF文件轉換為word或者PDF。RTF rich text format富文字。

一般情況下我會定義一個方法RTFUtil.rtf2word和RTFUtil.rtf2pdf直接去轉換就可以了。

在書中認為這個轉化過程是一個比較複雜的過程，那麼需要將轉換字串和轉換pdf中的圖片，連結等用不同的方法去表示，而且每一個轉換都定義一個單獨的類，而不是作為RTFUtil的一個方法。

UML圖如下：

這裡RTFReader是一個讀取類，成員屬性builder是Converter介面，Converter有兩個實現類，分別是word轉化器和PDF轉化器。

當RTF需要轉換成不同的目標格式的時候，只需要修改Converter實現類即可。

public static void main(String[] args){
  Converter converter = new WordConverter();
  //Converter converter = new PDFConverter();
  RTFReader rtfReader = new RTFReader(converter);
  rtfReader.parseRTF();
}

抽象出來的一般類圖如下

這裡Director起到的是排程的作用，他將需要組合的最終的各個部分排程起來，而各個部分的處理由Builder去處理。

這樣通過彼此解耦有了更好的處理。

但是這裡我有了一些小疑問，既然目標部分可以多樣化，為什麼源不能多樣化。

如可以是pdf2word，也可以是rtf2word，word2pdf。

在源和目標之間加一箇中間處理，將源的資料分析成目標可以處理的資料，然後組裝成一個產品。

這個設計模式應該在銷售中的產品訂單組裝成不同大物件有用。

構造器模式對構造過程把握的更精細，因為每一步是逐步組裝的。