1、前言
本週參加了第二次設計模式研討會，主題是生成器（Builder）模式，接下來咱們來看看該模式的具體內容。算法
2、生成器模式
生成器（Builder）模式是一個很經常使用模式。《設計模式——可複用面向對象軟件的基礎》書中說，它的意圖是將一個複雜對象的構建與它的表示分離，使得一樣的構建過程能夠建立不一樣的表示。設計模式
這句話剛開始看很難理解，什麼是構建、建立、表示？打個簡單的比方：假如咱們如今要建房子，房子是一個複雜對象（也就是最終產品），磚頭、鋼筋和水泥是建築材料（即複雜對象中包含的子對象），生產這些材料的過程就是所謂的構建，建房子的過程就是建立，房子的風格（好比宮殿、別墅等)就是所謂的表示。抽象點講：ui
- 構建：生成複雜對象中的子對象的過程——造磚、造水泥等；
- 建立：生成複雜對象的過程——拿磚頭造房子；
- 表示：最終複雜對象表現出來的形式——房子的風格；
也就是說，Builder模式就是讓制磚廠和建築公司分開，由建築公司決定房子的風格，讓一樣的磚頭能夠修建不一樣的房子，即一樣的子對象能夠生產不一樣複雜對象。設計
Builder模式主要解決：在軟件系統中，有時候面臨着「一個複雜對象」的建立，其一般由各個部分的子對象用必定算法構成；因爲需求的變化，這個複雜對象的各個部分常常面臨劇烈的變化，可是將它們組合在一塊兒的算法卻相對穩定。3d
簡單理解：系統中組成複雜對象的具體子對象易變，相同的子對象又能夠參與生成不一樣的複雜對象，但實際上組合複雜對象的方式是不變的，Builder模式將變與不變的部分分離開。對象
3、應用示例
XML是一種普遍使用的文件格式，自己是一個容器，能夠存放各類數據。blog
操做XML文件最簡單的方式是SAX（Simple API for XML），該方式採用了Builder模式，它把XML的 解析 和 建立表示 兩個過程分開了，而且只負責 解析 過程，由用戶本身負責 建立表示 的過程。遞歸
XML文件是遞歸結構，由tag和文本等基本元素組成，善始善終（<tag> </tag>），SAX解析器（Parser）會解析出基本元素，但並不把這些元素構成一顆DOM樹，而是把這些基本元素交給建立者Builder處理。至於Builder拿這些元素去幹什麼，SAX解析器是無論的。接口
可能拿去建立DOM樹，可能只是取某個tag的屬性，可能轉換成pdf文檔。圖片
從SAX例子中，能夠看出：採用Builder模式，重用瞭解析器的代碼，把變化的部分隔離到Builder裏。另一方面，分離 解析 和 建立 兩個過程，實際上也簡化了問題的複雜度，解析器部分只負責解析，實現更加容易。且Builder更瞭解本身的目標，實現會更加專業。
4、結構與參與者
Builder模式的結構圖：
- Builder：爲建立Product的各個部件指定抽象接口（解析器要求提供的接口）；
- ConcreteBuilder：Builder的具體實現，好比建立DOM樹；
- Director：構造一個使用Builder接口的對象（解析器Parser）；
- Product：被構造的複雜對象（最終產品）；
5、總結
優勢：隔離變與不變，簡化了問題複雜度；Builder獨立，易擴展。
缺點：產品必須有共同點（組合方式相同）；變化複雜時會有不少Builder 。
應用場景：須要生成的對象具備複雜的內部結構；須要生成的對象內部屬性自己相互依賴。
如：RTF閱讀器、歌詞解析、XML文件解析 等各種文本解析但具體表示不一樣的狀況。
與抽象工廠模式相比，生成器模式着重於關注零件的裝配，逐步構建複雜對象。
下一週我再嘗試使用Builder模式實現一個簡單的歌詞解析器。