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）模式：一個動作的演算法由多個步驟按照固定結構組成，而其中一些步驟的實作是多變的，就把這些多變的特定步驟放在子類中去重新定義，如從資料庫加載資料的程序：連接、獲取資料、處理資料、關閉連接，這個程序對于從資料庫中獲取任何資料的都是一樣固定不變的，但是獲取資料和處理資料對于不同的業務，他的實作細節是不一樣的，

標籤：設計模式

上一篇：設計模式學習筆記

下一篇：設計模式--裝飾器模式