實現
通常有乙個抽象的builder類為導向者可能要求建立的每乙個構件定義乙個操作。這些操作預設情況下什麼都不做。乙個concretebuilder類對它有興趣建立的構件重定義這些操作。
還是那句話，這並不是builder模式的專利，只要有抽象/具象關係就是這樣。
這裡是其他一些要考慮的實現問題：
1) 裝配和構造介面
生成器逐步的構造它們的產品。因此builder類介面必須足夠普遍，以便為各種型別的具體生成器構造產品。
這一點在前一篇文章中也提過，足夠普遍的意思是它足夠各個具象類生成各自的產品。
乙個關鍵的設計問題在於構造和裝配過程的模型。構造請求的結果只是被新增到產品中，通常這樣的模型就已足夠了。在rtf的例子中，生成器轉換下乙個標記並將它新增到它已經轉換了的正文中。
但有時你可能需要訪問前面已經構造了的產品部件。我們在**示例一節所給出的maze例子中，mazebuilder介面允許你在已經存在的房間之間增加一扇門。像語法分析樹這樣自底向上構建的樹型結構就是另乙個例子。在這種情況下，生成器會將子結點返回給導向者，然後導向者將它們回傳給生成者去建立父結點。
這段話想表達的是有時需要將建立的節點返回給director以便進行更精細的控制。我們無法找到語法分析樹中使用builder模式的例子，所以編寫了下面構建選單的例子。首先是抽象類：
buildmenu和builditem分別返回各自構建的節點，以便在additem中使用。
有一點需要注意的是，**中返回的節點的指標型別均為void*。這是因為不同的具象builder生成的節點型別之間一般是毫無關聯的。另外一點，director其實也不需要知道這些細節。
接下來看示例。假設有以下menu和menuitem類。
我們可以這樣實現生成選單的builder：
然後就可以像下面這樣編寫**：
程式執行結果如下：
我們得到了乙個簡單的選單。
同樣地，我們也可以另外實現乙個生成測試指令碼的builder。
這裡的menutester,itemcheck和前面的menu、menuitem沒有任何關係。
比較這兩個builder的實現也可以發現：抽象的行為一樣，具象的行為完全不同。
利用者側的**也幾乎一樣：
這裡的buildtest和前一段**中的buildtest是同乙個函式。
這段**的執行結果為：
內容是一連串的測試動作。
利用者只要使用不同的具象builder，就可以在毫不知情的情況下構建完全不同的產品。
作者觀點
可以這樣理解builder模式：相同的套路，構建不同的產品。
注：
本文中藍色粗體文字都引自《設計模式》一書。
Java設計模式（五） 建造者模式Builder
我們要建造乙個複雜的產品。比如 神舟飛船 iphone。這個複雜的產品的建立，有這樣乙個問題需要處理 要構建的物件，宇宙飛船 package com.iter.devbox.builder 宇宙飛船 author shearer public class airship public orbital...
Aha！設計模式 58 裝飾模式 2
示例 我們從前一篇文章中選取網路資料處理的例子寫一段python 中首先定義了資料處理基類dataprocessor,它有乙個process操作用於處理資料。datacreater是乙個普通的派生類，用於初始化資料。然後是decorator類，它定義了乙個資料成員processor，用於管理裝飾物件...
Aha！設計模式 78 命令模式 3
結構 參與者 協作 client建立乙個concretecommand物件並指定它的receiver物件。某invoker物件接收該concretecommand物件。invoker呼叫concretecommand物件的執行操作。concretecommand物件呼叫receiver的一些操作以執...