1. 程式人生 > >探索軟體設計模式(二)

探索軟體設計模式(二)

我們在前面的文章中已經介紹了一些軟體的設計模式,並給出了一些非軟體的例子。下面,讓我們繼續完成軟體設計模式的探索,來看看這些模式中的行為模式及例項。

行為模式


作者總結了十一種行為模式。這些模式可以在硬幣分類銀行、餐館訂餐、音樂、運輸、汽車修理、自動售貨機和家庭建築中找到例子。

職責鏈(Chain of Responsibility)舉例

職責鏈模式使得多個物件都有機會處理請求,從而避免請求的傳送者和接收者之間的耦合關係。機械硬幣分揀銀行使用職責鏈。這裡並不是為每一種硬幣分配一個滑槽,而是僅使用一個滑槽。當硬幣落下時,硬幣被銀行內部的機械導向至適當的接收盒。



圖13:使用硬幣分揀例子的職責鏈模式物件圖


命令(Command)模式

命令模式將一個請求封裝為一個物件,從而使你可以使用不同的請求對客戶進行引數化。用餐時的賬單是命令模式的一個例子。服務員接受顧客的點單,把它記在賬單上封裝。這個點單被排隊等待烹飪。注意這裡的"賬單"是不依賴於選單的,它可以被不同的顧客使用,因此它可以添入不同的點單專案。



直譯器(Interpreter)舉例

直譯器模式定義了特定語言的文法表示和解釋該文法的直譯器。音樂家是直譯器的例子。音階和它的持續時間可以用五線譜上的符號表示。這些符號就是音樂語言[14]。音樂家按照樂譜演奏,就可以反覆重現同樣的音樂。



迭代器(Iterator)舉例

迭代器提供一種方法順序訪問一個集合物件中各個元素,而又不需要暴露該物件的內部表示。在早期的電視機中,一個撥盤用來改變頻道。當改變頻道時,需要手工轉動撥盤移過每一個頻道,而不論這個頻道是否有訊號。現在的電視機,使用[後一個]和[前一個]按鈕。當按下[後一個]按鈕時,將切換到下一個預置的頻道。想象一下在陌生的城市中的旅店中看電視。當改變頻道時,重要的不是幾頻道,而是節目內容。如果對一個頻道的節目不感興趣,那麼可以換下一個頻道,而不需要知道它是幾頻道。



中介者(Mediator)舉例

中介者模式用一箇中介物件來控制一系列的物件互動。通過中介者實現各個物件之間的鬆散耦合,而不是彼此直接作用。機場的控制塔很好地演示了這種模式。降落或者起飛的飛機直接與塔臺通訊,而不是彼此間直接通訊。誰可以起飛或降落是由塔臺決定的。這裡需要注意的是塔臺並不控制整個飛行過程。它只負責飛機在機場附近的區域。



圖17:使用訓練中心為例子的中介者模式


備忘錄(Memento)舉例

備忘錄模式捕獲並且在外部儲存一個物件的內部狀態,使得以後可以將物件恢復到該狀態。這種模式通常體現在你自己修理汽車的剎車時。首先移開兩邊的擋板,露出左右剎車片。只能卸下一片,這時另一片作為一個備忘錄來表明剎車是怎樣安裝的。在這片修理完成後,才可以卸下另一片。當第二片卸下時,第一片就成了備忘錄。



觀察者(Observer)模式


觀察者定義了物件間一對多的關係,當一個物件的狀態變化時,所有依賴它的物件都得到通知並且自動地更新。拍賣演示了這種模式。每個投標人都有一個標有數字的牌子用於出價。拍賣師開始拍賣時,他觀察是否有牌子舉起出價。每次接受一個新的出價都改變了拍賣的當前價格,並且廣播給所有的投標人進行新的出價。



狀態(State)模式


狀態模式允許一個物件在其內部狀態改變時改變它的行為。這種模式可以在自動售貨機上觀察到。自動售貨機的狀態包括列商品清單,收款,找錢和選擇商品等幾種狀態。當投入硬幣並選擇了一個商品時,自動售貨機可以完成以下幾種操作,包括:送出商品不找錢、送出商品並找錢、由於投幣不足不送出商品、由於商品售完不送出商品。



策略(Strategy)模式


策略模式定義了一系列可以相互替換的演算法。不同的到飛機場去的方式就是一個策略模式的例子。有幾種選擇:自己開車、坐計程車、乘機場班車、乘公共汽車或使用專車服務等等。對於某些機場,地鐵和直升機也是可能的選擇。任何一種方式都可以把你送到機場,它們可以相互代替。你必須根據價格、便利性和時間做出選擇。



模板方法(Template Method)舉例

模板方法定義了一個操作中演算法的骨架,而將一些步驟延遲到子類中。房屋建築師在開發孿釒渴被崾褂媚0宸椒āR桓齙湫偷墓婊ㄒ恍┙ㄖ矯嬙跡扛銎矯嬙繼逑至瞬煌糠幀T諞桓銎矯嬙賈校鞀⒔峁埂⑸舷濾妥呦叨雜諉扛齜考潿際且謊摹V揮性誚ㄖ暮篤誆趴加脅畋鴝瞬煌姆課菅健?



訪問者(Visitor)舉例

訪問者模式表示一個作用於物件結構中各元素的操作,定義這個操作並不會改變元素的類。這種模式可以在出租車公司的運轉中觀察到。當一個人給出租車公司打電話時,他(她)就成了公司所有顧客的一員。然後公司指定一輛車去服務(接受訪問者)。在進入計程車之後,這個人(訪問者)就不再控制他(她)的旅程了,而是由計程車(駕駛員)負責。



意義


軟體設計模式有許多非軟體的例子存在。也許有人想知道這些例子的實際意義。非軟體例子有助於增進模式語言的表達力和輔助模式的學習。

增加模式語言的表達能力

Alexander覺得真正的模式要融入一種通用的語言以便所有人都能夠分享。在軟體設計的人群中,模式被認為是在同事之間一種約定俗成的開發方式。模式提供了一種比模組、過程和物件更高層次的概念。

一種語言中至關重要的因素是同語言形象所對應的心靈影像。在一種語言中,僅當一個人能夠領會一個符號的含義,能夠在心裡描繪出這種含義時,這個符號的外形才是有意義的。Alexander沒有忽視模式語言的這種重要特徵,他規定:一種語言只有在它所產生的建築型別能夠被具體地看到之後,這種語言才是完全形態化的。在軟體設計中,Richle和Züllighoven認識到具體的例子在指導我們對應用領域的理解的重要性。

如果軟體設計模式成為程式設計師中通用的語言,其基礎則是統一的含義。如果設計決定下達了,但是沒有被理解,則設計師被迫通過假設來完成工作。平凡的例子更便於理解,其原因在於人們必須在記憶中找到相關聯的內容才能夠理解。在廣泛使用模式的AG Communication Systems公司的專案中,常常使用非軟體例子來解釋模式之間的關係。這個例子有助於在設計師間提供統一的理解。通過在設計過程的先期建立統一的理解,使得在整個專案生命週期中,設計師間的溝通更加容易。

結論


在非軟體例子中軟體設計模式的體現表明了模式不是侷限於特定領域的。軟體設計師可以從這些日常事物的模式舉例中受益,哪怕這些例子並不是以程式設計語言表達的。這篇文章儘可能舉一些大部分人所熟悉的例子(儘管某些傾向於北美文化)。通過對共同的經歷的描述,這些例子有助於對特定的設計模式的理解,並且能夠幫助對設計模式的學習。