建立——構造器模式
阿新 • • 發佈:2018-11-07
英文名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。
在源和目標之間加一箇中間處理,將源的資料分析成目標可以處理的資料,然後組裝成一個產品。
這個設計模式應該在銷售中的產品訂單組裝成不同大物件有用。
構造器模式對構造過程把握的更精細,因為每一步是逐步組裝的。