如何編寫優雅的代碼：04. 設計模式(中)

前文詳細介紹了Façade模式、Adapter模式、Strategy模式和Bridge模式，並進行了比較。本文將再介紹四個經常使用的設計模式：Abstract Factory(抽象工廠)模式、Decorator(裝飾)模式、Observer(觀察者)模式、Template Method(模板)模式。開始介紹以前，筆者想說一下本身常常糾結的一個問題，何時開始考慮應用模式？做爲一個新手，剛接觸設計模式時都會爲之傾倒，自覺醍醐灌頂，很是的迫切將所學的設計模式應用於實踐，因此在編程的初期就會考慮各類模式的應用。我的的經驗告訴我，對業務的理解是一個漸進明細的過程，開發的初期每每很難看到整個業務需求的全貌和本質，此時強行應用設計模式每每會致使Over Engineering。筆者認爲應用設計模式的最佳時機每每是在代碼重構的時候，彼時你已掌握業務的本質，對模式的應用每每可以恰到好處，其實這也是JIT的思想。

一．Abstract Factory模式

1. 目標：須要爲特定的客戶（或狀況）提供對象組，組內之間的對象處於一個上下文環境。

2. 問題：須要實例化一組相關的對象，並從對象建立邏輯層面保證對象之間正確的關係，例如：在遊戲設計中，在非洲大陸，不可以建立出美洲豹對象。

3. 解決方案：協調對象組的建立。提供一種方式，將如何執行對象實例化的規則從使用這些對象的客戶對象中提取出來，實現對象建立和對象使用的解耦。

4. 參與者和協做者：Abstract Factory爲如何建立對象組的每一個成員定義公共接口。特定的ConcreteFactory建立其所對應的具體對象組。

5. 效果：抽象工廠模式將「使用那些對象」的規則與「如何使用這些對象」的邏輯進行解耦，實現關注點分離。

6. 實現：定義一個抽象類來指定建立哪些對象。而後爲每一個組實現一個具體類。代碼請參考06. 設計模式應用案例(上)。UML圖以下：

二．Decorator模式

1. 目的：在運行時，實現動態的爲每個對象添加職責。

2. 問題：要使用的對象將執行所須要的基本功能。可是，這些基本功能肯定之後，可能須要爲這個對象添加一些其餘的附加功能，而且對於不一樣的狀況可能添加的附加功能的種類和數量都是不肯定的。

3. 解決方案：經過添加裝飾類，而不是擴展子類，在運行時爲基本類對象擴充功能。抽象的說：有一個基本功能，還有些可選功能，每個具體的對象，在基本功能的基礎上經過選用不一樣的可選功能來定製。基本功能做爲：ConcreteComponent；可選功能做爲：ConcreteDecorator。

4. 參與者和協做者：ConcreteComponent讓Decorator對象爲本身添加功能。有時候用ConcreteComponent的派生類提供核心功能，在這種狀況下ConcreteComponent再也不是具體的，而是抽象的。Component類定義了全部這些類的接口。

5. 效果：附加功能放在Decorator對象中。好處是能夠在ConcreteComponent對象的功能以前或以後添加功能(取決於Decorator類的具體實現)，可是對象鏈老是終於ConcreteComponent對象。

6. 實現：建立一個抽象類來表示原類和要添加到這個類的功能。在裝飾類中，將對新功能的調用放在對緊隨其後對象的調用以前或以後，以得到正確的順序。調用方式爲new ConcreteDecorator(new ConcreteComponent())。代碼請參考07. 設計模式應用案例(下)。UML圖以下：

三．Observer模式

1. 目標：解開觀察者和主體之間的耦合，兩者之間的關係在運行時動態創建，實現訂閱--發佈模型(Pub-Sub Model).

2. 問題：對象間常常存在這樣一種關係：某個對象狀態的改變將致使另外一些對象的狀態變化。或者說，有些對象做爲觀察者在始終盯着某個對象，一旦有事發生就須要當即行動。抽象的說：當主體發生變化時，不一樣的觀察者作出不一樣的行動，並且他們的行動是自我控制的，無需主體發出指令。

3. 解決方案：經過將主體和觀察者分開，而不是簡單的將觀察者的行爲硬編碼到主體類中，觀察者經過監測主體類的實踐實現自我控制。

4. 參與者和協做者：Subject由三個函數構成：Attach（添加新的觀察者）、Detach（刪除過期的觀察者）、Notify（依次更新觀測者的信息）；Observer定時更新本身的狀態，根據主體的變化，作出相應的反應。

5. 效果：觀察者對主體而言是透明的，觀察者能夠自發的作出反應。

6. 實現：建立一個Subject類，包含有三個函數。還有一個ConcreteSubject類得到主體的狀態信息。建立一個Observer的抽象基類，還有不一樣觀測者的ConcreteObserver類，定時更新本身的信息。代碼請參考07. 設計模式應用案例(下)。UML圖以下：

四．Template Method模式

1. 目標：定義業務邏輯中算法的骨架，將一些步驟推遲到子類中實現。能夠不改變算法的結構而從新實現這個算法中的某些步驟。

2. 問題：要完成在某一細節層次一致的一個過程或一系列步驟，但其中個別步驟在更細節的層次上有不一樣的實現。

3. 解決方案：容許定義可變的子步驟，同時保持基本步驟和步驟之間的執行順序不變。

4. 參與者和協做者：Abstract Class，該類中有一個定義了通常算法的方法（Template Method）這個方法調用了表明算法中各步驟的方法（Primitive Operation）。Concrete Class，實現Primitive Operation以完成算法中與特定子類相關的步驟。

5. 效果：提供了一個很好的代碼複用平臺，而且從結構上減小了算法出錯的機率。同時，提供了一種機制，使得約束、規則能夠一次編碼，到處使用。對於具體類的實現者而言，無需關注整個算法，只需關注該具體類中特殊的實現邏輯便可。

6. 實現：建立一個抽象類，用抽象方法實現一個過程。這些抽象方法必須在子類中實現，以執行過程的每一個步驟。若是這些步驟是獨立變化的，那麼每一個步驟均可以是Strategy模式來實現(不少狀況下，模式都不是獨立使用，而是組合使用)。代碼請參考07. 設計模式應用案例(下)。UML圖以下：