Aha！設計模式(11)-BUILDER(2)
動機
《設計模式》中關於BUILDER動機的說明使用的是RTF文件格式轉換的例子。這個例子本身很容易理解，這裡就不再重複了。本文只講作者本人的見解。
還是那一招
本連載提到過：大部分情況下，設計模式也好，面向物件也好其實就是一招，多型。這個結論對於BUILDER模式同樣使用。具體到《設計模式》中的例子，希望變化的就是輸出的型別或者說格式。基於這個想法，即使我們沒有學習設計模式，也可以進行基本的思考。
對於一個格式轉換處理來講，至少應該包括下面三個步驟：讀入資料，處理資料，輸出資料。本文的內容是BUILDER設計模式，所以我們將焦點定在輸出上。我們可以這樣這樣設計。
按照上面的設計，當我們希望追加一種新的輸出格式時，只要增加新的具象類就可以了。
足夠簡單的類
上述設計在輸出內容簡單的時候沒有什麼問題，當輸入內容比較複雜的時候，會有一些問題：
-
除了真正的輸出以外，至少還會包含另外的處理，例如資料結構的遍歷，有的時候也會包含解析的內容。
-
各個類中處理資料共同結構（頁，段落等）的部分應該很類似，只是具體輸
出的部分有所不同。
解決這些問題的方法就是進一步分離共通處理，讓FileWriter只處理真正不同的部分，其他資料遍歷等內容則交給其他的類。
走到這一步，基本就和BUILDER模式沒啥區別了。下圖是BUILDER設計模式中動機部分的類圖。
這兩個類圖主要有三個區別：
-
類名不同，作者使用的Writer而不是Converter，是希望更加明確地表示類的功能只包含最後輸出的功能。
-
builder/writer的位置。這兩個名詞都是用來指定Converter/Writer資料成員的名稱的。《設計模式》書中標在了RTFReader一側，而作者的圖中標在了Writer一側。哪種情況正確，大家可以參照UML方面的書籍。
-
作者的例子另外增加了begin/end方法，這種方式下對應的具象類會比較容易實現。
無論誰是誰非，BUILDER的思想都是不變的。
作者觀點
一個類只幹一件事。
大道至簡，這個原則應該可以很好地詮釋這句話。
覺得本文有幫助？請分享給更多人。
閱讀更多更新文章，請掃描下面二維碼，關注微信公眾號【面向物件思考】
