我們在
前面的文章中已經介紹了一些軟體的設計模式，並給出了一些非軟體的例子。下面，讓我們繼續完成軟體設計模式的探索，來看看這些模式中的行為模式及例項。
行為模式
作者總結了十一種行為模式。這些模式可以在硬幣分類銀行、餐館訂餐、**、運輸、汽車修理、自動售貨機和家庭建築中找到例子。
職責鏈（chain of responsibility）舉例
職責鏈模式使得多個物件都有機會處理請求，從而避免請求的傳送者和接收者之間的耦合關係。機械硬幣分揀銀行使用職責鏈。這裡並不是為每一種硬幣分配乙個滑槽，而是僅使用乙個滑槽。當硬幣落下時，硬幣被銀行內部的機械導向至適當的接收盒。
圖13：使用硬幣分揀例子的職責鏈模式物件圖
命令（command）模式
命令模式將乙個請求封裝為乙個物件，從而使你可以使用不同的請求對客戶進行引數化。用餐時的賬單是命令模式的乙個例子。服務員接受顧客的點單，把它記在賬單上封裝。這個點單被排隊等待烹飪。注意這裡的"賬單"是不依賴於選單的，它可以被不同的顧客使用，因此它可以添入不同的點單專案。
直譯器（interpreter）舉例
直譯器模式定義了特定語言的文法表示和解釋該文法的直譯器。**家是直譯器的例子。音階和它的持續時間可以用五線譜上的符號表示。這些符號就是**語言[14]。**家按照樂譜演奏，就可以反覆重現同樣的**。
迭代器（iterator）舉例
迭代器提供一種方法順序訪問乙個集合物件中各個元素，而又不需要暴露該物件的內部表示。在早期的電視機中，乙個撥盤用來改變頻道。當改變頻道時，需要手工轉動撥盤移過每乙個頻道，而不論這個頻道是否有訊號。現在的電視機，使用[後乙個]和[前乙個]按鈕。當按下[後乙個]按鈕時，將切換到下乙個預置的頻道。想象一下在陌生的城市中的旅店中看電視。當改變頻道時，重要的不是幾頻道，而是節目內容。如果對乙個頻道的節目不感興趣，那麼可以換下乙個頻道，而不需要知道它是幾頻道。
中介者（mediator）舉例
中介者模式用乙個中介物件來控制一系列的物件互動。通過中介者實現各個物件之間的鬆散耦合，而不是彼此直接作用。機場的控制塔很好地演示了這種模式。降落或者起飛的飛機直接與塔台通訊，而不是彼此間直接通訊。誰可以起飛或降落是由塔台決定的。這裡需要注意的是塔台並不控制整個飛行過程。它只負責飛機在機場附近的區域。
圖17：使用訓練中心為例子的中介者模式
備忘錄（memento）舉例
備忘錄模式捕獲並且在外部儲存乙個物件的內部狀態，使得以後可以將物件恢復到該狀態。這種模式通常體現在你自己修理汽車的剎車時。首先移開兩邊的擋板，露出左右剎車片。只能卸下一片，這時另一片作為乙個備忘錄來表明剎車是怎樣安裝的。在這片修理完成後，才可以卸下另一片。當第二片卸下時，第一片就成了備忘錄。
觀察者（observer）模式
觀察者定義了物件間一對多的關係，當乙個物件的狀態變化時，所有依賴它的物件都得到通知並且自動地更新。拍賣演示了這種模式。每個投標人都有乙個標有數字的牌子用於出價。拍賣師開始拍賣時，他觀察是否有牌子舉起出價。每次接受乙個新的出價都改變了拍賣的當前**，並且廣播給所有的投標人進行新的出價。
狀態（state）模式
狀態模式允許乙個物件在其內部狀態改變時改變它的行為。這種模式可以在自動售貨機上觀察到。自動售貨機的狀態包括列商品清單，收款，找錢和選擇商品等幾種狀態。當投入硬幣並選擇了乙個商品時，自動售貨機可以完成以下幾種操作，包括：送出商品不找錢、送出商品並找錢、由於投幣不足不送出商品、由於商品售完不送出商品。
策略（strategy）模式
策略模式定義了一系列可以相互替換的演算法。不同的到飛機場去的方式就是乙個策略模式的例子。有幾種選擇：自己開車、坐計程車、乘機場班車、乘公共汽車或使用專車服務等等。對於某些機場，地鐵和***也是可能的選擇。任何一種方式都可以把你送到機場，它們可以相互代替。你必須根據**、便利性和時間做出選擇。
模板方法（template method）舉例
模板方法定義了乙個操作中演算法的骨架，而將一些步驟延遲到子類中。房屋建築師在開發孿釒渴被崾褂媚０宸椒āｒ桓齙湫偷墓婊ㄒ恍┙ㄖ矯嬙跡扛銎矯嬙繼逑至瞬煌糠幀ｔ諞桓銎矯嬙賈校鞀⒔峁埂⑸舷濾妥呦叨雜諉扛齜考潿際且謊摹ｖ揮性誚ㄖ暮篤誆趴加脅畋鴝瞬煌姆課菅健?
訪問者（visitor）舉例
訪問者模式表示乙個作用於物件結構中各元素的操作，定義這個操作並不會改變元素的類。這種模式可以在計程車公司的運轉中觀察到。當乙個人給計程車公司打**時，他（她）就成了公司所有顧客的一員。然後公司指定一輛車去服務（接受訪問者）。在進入計程車之後，這個人（訪問者）就不再控制他（她）的旅程了，而是由計程車（駕駛員）負責。
意義
軟體設計模式有許多非軟體的例子存在。也許有人想知道這些例子的實際意義。非軟體例子有助於增進模式語言的表達力和輔助模式的學習。
增加模式語言的表達能力
alexander覺得真正的模式要融入一種通用的語言以便所有人都能夠分享。在軟體設計的人群中，模式被認為是在同事之間一種約定俗成的開發方式。模式提供了一種比模組、過程和物件更高層次的概念。
一種語言中至關重要的因素是同語言形象所對應的心靈影像。在一種語言中，僅當乙個人能夠領會乙個符號的含義，能夠在心裡描繪出這種含義時，這個符號的外形才是有意義的。alexander沒有忽視模式語言的這種重要特徵，他規定：一種語言只有在它所產生的建築型別能夠被具體地看到之後，這種語言才是完全角態化的。在軟體設計中，richle和züllighoven認識到具體的例子在指導我們對應用領域的理解的重要性。
如果軟體設計模式成為程式設計師中通用的語言，其基礎則是統一的含義。如果設計決定下達了，但是沒有被理解，則設計師被迫通過假設來完成工作。平凡的例子更便於理解，其原因在於人們必須在記憶中找到相關聯的內容才能夠理解。在廣泛使用模式的ag communication systems公司的專案中，常常使用非軟體例子來解釋模式之間的關係。這個例子有助於在設計師間提供統一的理解。通過在設計過程的先期建立統一的理解，使得在整個專案生命週期中，設計師間的溝通更加容易。
結論
在非軟體例子中軟體設計模式的體現表明了模式不是侷限於特定領域的。軟體設計師可以從這些日常事物的模式舉例中受益，哪怕這些例子並不是以程式語言表達的。這篇文章盡可能舉一些大部分人所熟悉的例子（儘管某些傾向於北美文化）。通過對共同的經歷的描述，這些例子有助於對特定的設計模式的理解，並且能夠幫助對設計模式的學習。
設計模式探索 原型模式
原型模式 prototype pattern 是用於建立重複的物件，同時又能保證效能。這種型別的設計模式屬於建立型模式，它提供了一種建立物件的最佳方式。uml圖 1.建立實現了clonable的抽象類 public abstract class shape implements clonable p...
探索設計模式之三 抽象工廠模式
前面介紹的 簡單工廠模式 和 工廠方法模式 立足點都是避免顯式的建立具體物件，封裝建立物件時可能出現的變化點，這已經能比較好的解決單個物件建立的問題，但實際業務中，還經常出現需要一系列物件互相關聯使用來完成任務的情況。對於存在關聯 以來的產品來說，使用簡單工廠或者工廠方法乙個乙個的建立其中的具體產品...
設計模式（二） 原型設計模式
官方定義 使用原型例項指定建立物件的種類，並通過複製這個原型建立新的物件 通俗的講就是根據乙個原型建立乙個新的物件 建立的方式實質就是拷貝原型自己 而且不需要知道新物件建立的細節 1 某些物件組合起來特別複雜，而重新建立費時又費力，此時通過拷貝能達到其目的 通過 說明問題 1 定義乙個協議 impo...