常見設計模式要點總結

最近在看《head first 設計模式》，發現每個章節後的要點總結都是言簡意駭，所以特寫此篇部落格對常見的設計模式要點做個總結。

在物件之間定義一對多的依賴，這樣一來，當乙個物件改變狀態，依賴它的物件都會收到通知，並自動更新

●抽象主題(subject)角色：抽象主題角色把所有對觀察者物件的引用儲存在乙個聚集（比如arraylist物件）裡，每個主題都可以有任何數量的觀察者。抽象主題提供乙個介面，可以增加和刪除觀察者物件，抽象主題角色又叫做抽象被觀察者(observable)角色。

●具體主題(concretesubject)角色：將有關狀態存入具體觀察者物件；在具體主題的內部狀態改變時，給所有登記過的觀察者發出通知。具體主題角色又叫做具體被觀察者(concrete observable)角色。

●抽象觀察者(observer)角色：為所有的具體觀察者定義乙個介面，在得到主題的通知時更新自己，這個介面叫做更新介面。

●具體觀察者(concreteobserver)角色：儲存與主題的狀態自恰的狀態。具體觀察者角色實現抽象觀察者角色所要求的更新介面，以便使本身的狀態與主題的狀態像協調。如果需要，具體觀察者角色可以保持乙個指向具體主題物件的引用。

動態的將責任加到物件上，想要擴充套件功能，裝飾者提供有別於繼承的另一種選擇

在裝飾模式中的角色有：

●抽象構件(component)角色：給出乙個抽象介面，以規範準備接收附加責任的物件。

●具體構件(concretecomponent)角色：定義乙個將要接收附加責任的類。

●裝飾(decorator)角色：持有乙個構件(component)物件的例項，並定義乙個與抽象構件介面一致的介面。

●具體裝飾(concretedecorator)角色：負責給構件物件「貼上」附加的責任。

簡單工廠：定義了乙個建立物件的介面，但由子類決定要例項化的類是哪乙個。

下圖是簡單工廠模式的uml圖

簡單工廠的關注點是產品，如上圖中的cpufactory，mainboardfactory。當我們需要新增乙個產品的時候（例如memory 就不需要對原有**進行修改），但是當我們需要新增一種cpu的時候（例如huawei cpu)簡單工廠就需要對原有**改動了，於是我們引入第二種抽象工廠。

抽象工廠的關注點是產品族，如上圖中的intelfactory，amdfactory。當我們需要新增乙個產品族的時候（例如huaweifactory 就不需要對原有**進行修改），但是當我們需要新增一種產品的時候（例如memory)抽象工廠就需要對原有**改動了。

以上兩種工廠模式，各有優劣。

確保乙個類只有乙個例項並提供全域性訪問點

推薦一種單例模式的最佳實踐

publicclasssingleton
privatestaticclassinstanceholder
publicsingletongetsingleton
()}複製**

介面卡模式：將乙個類的介面轉換成期望的另乙個介面，介面卡讓原本不相容的類可以合作無間

門面模式：提供了乙個統一的介面用來訪問子系統的一群介面。外觀定義了乙個高層介面使得子系統更加易用

介面卡uml圖

模式所涉及的角色有：

●目標(target)角色：這就是所期待得到的介面。注意：由於這裡討論的是類介面卡模式，因此目標不可以是類。

●源(adapee)角色：現在需要適配的介面。

●介面卡(adaper)角色：介面卡類是本模式的核心。介面卡把源介面轉換成目標介面。顯然，這一角色不可以是介面，而必須是具體類

門面模式相對比較簡單

上圖是我暑假在阿里實習做的乙個小需求。其中核身元件就用到了門面模式，將核身元件這個領域物件暴露給前端，使得前端不必關注具體的每個核身項，從乙個複雜的子系統中解耦。

乙個替身或佔位符以訪問這個物件

在**模式中的角色：

●抽象物件角色：宣告了目標物件和**物件的共同介面，這樣一來在任何可以使用目標物件的地方都可以使用**物件。

●目標物件角色：定義了**物件所代表的目標物件。

●**物件角色：**物件內部含有目標物件的引用，從而可以在任何時候操作目標物件；**物件提供乙個與目標物件相同的介面，以便可以在任何時候替代目標物件。**物件通常在客戶端呼叫傳遞給目標物件之前或之後，執行某個操作，而不是單純地將呼叫傳遞給目標物件。

想要學習設計模式的初衷是，如何寫出更靈活，更健壯，更符合規範的**。也確實從設計模式的學習中感受到了物件導向的強大，不過紙上得來終覺淺，絕知此事要躬行。

《head first 設計模式》

[23種設計模式的深入理解] 23種設計模式的深入理解