23種GoF設計模式概述

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