23種GoF設計模式概述

在前面，我們對 GoF 的 23 種設計模式進行了分類，這裡先對各個設計模式的功能進行簡要介紹，以便有個大概瞭解。後面的章節再進行詳細介紹。

創建型模式

關註於怎麼創建對象的創建型模式，他們將對象的創建與使用相互分離，對象的使用者無需關心如何創建對象，只知道怎麼使用就行，以降低耦合度。猶如汽車使用人無需關註汽車是怎麼造出來一樣，只要知道怎麼使用就行。下麵這5種模式就是屬於這一類。

• 單例（Singleton）模式：控制某個類只能自行生成一個可供外部全局訪問的實例。例如：Windows的視窗管理器或者任務管理器都是只有一個實例。
• 原型（Prototype）模式：將一個創建成本高（如：裝載大文件、初始化耗時長、CPU資源占用多等）的對象作為原型，通過對其進行複製或者克隆，來創建其他類似的新實例。
• 抽象工廠（Abstract Factory）模式：由繼承自抽象工廠類的具體工廠分別來創建有相同聯繫的多個不同產品。例如不同的培訓學校，可以創建課程和課程所用的教材。
• 建造者（Builder）模式：針對一個複雜對象，它的構建需要很多步驟和部件，將這種對象拆解成多個相對簡單的構成部件或者步驟，然後再根據需要分別構建他們，直到得到該複雜對象。例如：快餐店的套餐，他的構造分別由漢堡、飲料、薯條構成，這就要求建造或製作者分別創建各種物品，然後返回一個完整的套餐給點餐人員。
• 工廠方法（Factory Method）模式：由繼承自抽象工廠類的具體工廠來決定生成什麼具體產品。例如都屬於傢具廠的沙發工廠、桌椅工廠和床廠分別生產沙發、桌椅和床這些傢具。

結構型模式

這種模式關註如何將對象和類按照某種方式一起來構成新的、更大、更有效果的低耦合結構，這種組成方式用於類結構的繼承、和用於對象結構的組合或聚合。具有組合或聚合關係的各對象之間要比繼承關係的各對象之間的耦合度弱，這樣對象結構要比類對象具有更低的耦合度。屬於結構模式的7種設計模式如下：

• 橋接（Bridge）模式：該模式含有兩個類，一個抽象類和實現類，在抽象類中（註意，這裡的抽象類不是繼承裡面所說的抽象類）通過對現實類的引用（該引用就像橋一樣把抽象類和實現類連接了起來），來實現了抽象與實現分離，使它們都可以進行獨立變化。這種模式採用了組合關係，而不是繼承關係來實現，從而降低了抽象和實現這兩個可變維度的耦合度。
• 裝飾（Decorator）模式：動態地給對象增加新的狀態和行為，來使其獲得其他額外的功能。這種擴展功能的方式比採取繼承來生成子類的實現方式更為靈活。這種模式關鍵點是裝飾器在繼承被裝飾類的同時又包含它的實例。
• 代理（Proxy）模式：客戶端通過代理對象來間接地訪問某個複雜對象。代理在這裡作為複雜對象的微型介面，起到了控制著訪問該複雜對象的功能，這些控制包括而限制、強化、驗證或修改該對象的一些特性。代理模式最常見的如一些訪問遠程服務的本地代理類。
• 外觀（Facade）模式：基於多個複雜的子系統的介面，在其上面提供一個更高層次的對外的一致的介面，方便這些子系統已被使用和訪問。例如一鍵購物，其中訂單，送貨地址、收款等都在此一步完成，這裡就用到了外觀模式。
• 享元（Flyweight）模式：根據是否隨著環境變化，區分出對象可變和不可變兩種狀態，也就是外部狀態和內部狀態，將不變的內部狀態作為共用部分需要實現的公共介面，可變的外部以參數的形式傳入方法，以此來支持大量細粒度對象的復用。
• 組合（Composite）模式：將對象進行層次結構化組合，如樹狀層次結構，使得用戶可以以同樣的方式對一個或者一組對象進行處理。也就是說用戶對單個對象和組合對象具有一致的訪問性。例如Windows的文件資源管理器，你可以對一個文件、一個文件夾進行同樣的操作。
• 適配器（Adapter）模式：為瞭解決介面的不相容問題，將一個類的介面轉換成客戶可以使用的另外一個介面，使得他們可以一起工作。例如，你要使用第三方組件，但是你目前系統中的介面跟其不同，而你又不願意對其改動，就需要使用適配器來解決這種問題。

行為型模型

行為型模式用於處理多個類或對象之間如何交互及相互協作的問題或者說運行時的流程式控制制，對象職責的分配和演算法控制都屬於他的處理範疇。下麵11種設計模式就屬於這種類型：

• 職責鏈（Chain of Responsibility）模式：將多個具有共同介面的請求處理器對象連成一條處理鏈條，請求從鏈中第一個對象開始往後傳遞，直到請求被處理為止。報銷審批的逐級上報就是典型的例子。
• 命令（Command）模式：將請求封裝成命令對象來解耦請求發出者與執行者之間的關係。餐廳點餐就是一個具體的例子，菜單時命令，廚師時接收者，服務員或者顧客就是命令發出者。
• 觀察者（Observer）模式：一個對象和一個或多個對象之間存在著依賴關係，當這個對象狀態發生改變時，相關依賴的對象就會自動得到通知並做出相應響應。這種模式也叫做發佈-訂閱模式。如客戶關註的熱銷產品價格的變動與客戶的關係。
• 中介者（Mediator）模式：建立一個中間人來處理多個對象之間的相互交互。這樣各對象都變成了跟中間人交互，而不是對象之間的相互交互。這樣可以降低對象間的耦合度，使原有對象之間不必直接相互引用。就如一個網狀結構變成了一個星狀結構，彼此間依賴減少。例如微信群就是一個典型的中介者例子，所有群員可以通過微信群之間相互交互，而不是彼此之間進行。
• 狀態（State）模式：針對有狀態的對象，將其改變狀態的行為抽取封裝到狀態中，這樣有狀態的對象在其內部狀態發生改變時，其行為也發生了改變，從而改變了對象的行為。這種模式常見於工作流或者游戲等系統中。例如，經費的批准有未辦、正在審核、正在處理、已經完成等狀態。
• 迭代器（Iterator）模式：對於聚合對象中的集合元素，在不用瞭解其內部結構的情況下，給其提供一種可以順序訪問該集合的介面。常見如圖片瀏覽應用，其中可以通過首圖、上一張，下一張、末圖來查看圖片，就是典型的迭代器模式應用。
• 訪問者（Visitor）模式：在不改變原有類型定義的情況下，對在已有結構中的所有元素上定義並執行新操作。這樣，每個元素都可以提供多種新操作，即每個元素有多個訪問者對象訪問，並對其執行新的操作。常見如超市購買的商品，各種各樣，有的需要稱重，有的需要打包，收銀員需要對他們掃碼計價，這些不同的操作都可以通過訪問者模式來實現。
• 備忘錄（Memento）模式：如果要記錄某一對象的狀態變化以便在某一時刻進行恢復，則該對象就可以將其以前狀態以備忘錄（對象）方式進行封裝，並將備忘錄對象交給備忘錄管理器進行管理存放，以便後續使用。我們常見的撤銷（Undo)就是這種方式實現。
• 策略（Strategy）模式：很多時候，對於給定的問題有很多種演算法或者策略來解決。為了避免將這些所有演算法以條件分支語句放在宿主類中，我們可以將每個演算法抽離出來形成一個具有類，所有這些演算法都繼承或實現一個同樣的抽象類或介面，並用一個上下文環境類對其各演算法或策略進行選擇和持有，並作為客戶端的入口。例如各種排序演算法就可以用這種方式來組織。
• 解釋器（Interpreter）模式：用於解釋用一種語言或者表示法定義的指令或語句。類似於編譯器來解釋代碼。
• 模板方法（Template Method）模式：一個動作的演算法由多個步驟按照固定結構組成，而其中一些步驟的實現是多變的，就把這些多變的特定步驟放在子類中去重新定義。如從資料庫載入數據的過程：連接、獲取數據、處理數據、關閉連接，這個過程對於從資料庫中獲取任何數據的都是一樣固定不變的，但是獲取數據和處理數據對於不同的業務，他的實現細節是不一樣的。