設計模式概述

以《大話設計模式》爲主，參考了一位大神的博客，總結一下24種設計模式。

模式分類

六大設計原則：單一職責原則，開放封閉原則，依賴倒轉原則，迪米特法則，接口隔離原則， 里氏替換原則。
創建型：簡單工廠模式，工廠模式，抽象工廠模式，建造者模式，原型模式，單例模式
結構型：代理模式，適配器模式，裝飾器模式，橋接模式，組合模式，享元模式，外觀模式
行爲型：觀察者模式，模板方法模式，命令模式，狀態模式，職責鏈模式，解釋器模式，中介者模式，訪問者模式，策略模式

模式簡介

設計原則

單一職責原則：每個類只負責單一的功能。

1. 單一職責意味着開發時要將類的功能區分開來，降低類與類之間的耦合，這樣可以避免改變一個類會影響其他類的功能
2. 將類之前的職責分離，可以提高系統的可維護性。

開放封閉原則：對擴展開放，對修改封閉。

1. 任何的改變都不需要修改代碼，只需要增加新的代碼就可以實現需要的功能。這是代碼的最理想的境界。

依賴倒轉原則：高層模塊不應該依賴於底層模塊，二者都依賴於抽象。抽象不應該依賴於細節，細節應該依賴抽象。

1. 針對接口編程，不要針對實現編程。

迪米特法則：也稱最小知道原則，如果兩個類不必彼此直接通信，那麼就不應當發生直接的相互作用。

1. 一個類不應該知道其他類的太多東西。實現高內聚性，低耦合性

接口隔離原則：也稱接口最小化原則，即一個接口擁有的行爲應該儘可能小。

1. 接口內的方法應該儘可能的少，過多的方法會強制實現類實現不必要的方法，往往會造成空方法，這樣會使得調用時沒有獲取到相應的結果。

里氏替換原則：子類可以替換父類並正常工作。

創建型模式

簡單工廠模式：從設計模式的類型上來說，簡單工廠模式是屬於創建型模式，又叫做靜態工廠方法（Static Factory Method）模式，但不屬於23種GOF設計模式之一。簡單工廠模式是由一個工廠對象決定創建出哪一種產品類的實例

• 設計原則：遵循單一原則，違背開閉原則
• 簡單工廠模式實質上是由一個工廠類根據傳入的參數，動態的決定應該創建哪一種產品。

• 缺點：簡單工廠模式違背了高內聚原則，如果要添加新的類，就必須改變工廠類的判斷邏輯。

  
  
  工廠模式：定義一個創建產品對象的工廠接口，將實際創建工作推遲到子類當中。核心工廠不再負責創建產品，而是作爲具體工廠子類的接口。

• 設計原則：遵循單一職責，開閉原則，依賴倒置
• 工廠模式意味着每一個具體的產品都由一個具體的工廠去創建，該具體工廠是核心抽象工廠的一個實現。將客戶端與具體的產品分離。

• 缺點：工廠模式增加了系統的複雜度，沒創建一個具體的產品都要新增一個具體的工廠實現。
  
  
  抽象工廠模式：爲創建一組相關或相互依賴的對象提供一個接口，而且無需指定他們的具體類。
  

• 設計原則：遵循單一職責，開閉原則，依賴倒置

• 定義中的接口指的就是Createor，他可以創建一組相關或者依賴的產品，而且創建的對象不是具體的類，而是一個接口或者一個抽象類，即ProductA和ProductB。工廠模式只能創建一種抽象產品，當需要需要創建新的抽象產品時，就要使用抽象工廠。實際上，這兩種抽象產品是有關聯的，比如同一數據庫的不同表就是不同的抽象產品，每個表由於數據庫的不同會有不同的實現方式，而它們又可以組合在同一種具體數據庫中，此時，數據庫就是一個Creator工廠，不同的數據庫就是具體工廠，而不同的表就是不同的抽象產品，它們以不同的具體實現，組合在具體工廠當中。
• 缺點：抽象工廠進一步增加了系統的複雜度，而且沒增加一個產品都需要修改抽象工廠和所有的具體工廠，並新增抽象類和所有的實現類。所以抽象工廠適用於抽象產品種類較多且數目不易更改，但實現不同的環境中。

建造者模式：將一個複雜對象的構建與它的表示相分離，使得同樣的構鍵過程可以創建不同的表示。

• 設計原則：遵循單一職責、開閉原則
• 建造者模式讓客戶端不用關心具體的構建過程和表示，只需要指定類型就可以得到具體的對象。
• 適用於對象的構建複雜，表示和構建相分離

原型模式：用原型實例指定創建對象的種類，並且通過拷貝這些原型創建新的對象

• 設計原則：無
• 簡單來說就是通過實例指定種類，通過拷貝創建對象。
• 優點： java中，clone方法是從虛擬機直接複製內存塊執行，比通過new創建對象要快；通過原型直接創建對象，不需要知道創建細節；可以在運行時動態獲取對象的類型以及狀態，從而創建一個對象。
• 適用於快速創建構建複雜的對象；運行時不知道對象的具體類型，動態的創建對象。

單例模式：保證系統中一個類只有一個實例

• 設計原則：無
• 使用單例模式的類，在整個系統中，同一時刻只能有一種狀態。在實踐中，許多應用級別的類都會被作成單例，比如配置文件。

• 注意：儘量使用標準的構建模式，以防併發時產生多個實例。

  
  
  
  

結構型

代理模式：爲其他對象提供一種代理以控制對這個對象的訪問

• 設計原則：體現功能複用
• 靜態代理一般持有一個被代理的對象，代理會在該對象原來的功能上修改或添加部分新的功能，比如數據庫連接時的關閉等工作。

適配器模式：將一個類的接口轉換成客戶希望的另一個接口。 Adapter模式使得原本由於接口不兼容而不能一起工作的哪些類可以一起工作。
- 設計原則：遵循開閉原則、體現功能複用
- 從實現方式上分爲兩種，類適配器和對象適配器，一種採用繼承，一種採用組合。從使用目的上，又分爲特殊適配器和缺省適配器
- 類適配器通常針對適配目標是接口的情況。由於java是單繼承，所以當適配目標是類或者需要複用多個類的時候要使用對象適配器
- 注意：適配期模式通常是雙方都無法再修改時候使用的，是一種補救措施。

裝飾器模式：動態的給一個對象添加一些額外的職責，就增加功能來說，裝飾器比子類更加靈活。

• 設計原則：遵循迪米特、單一職責、開閉原則，破壞里氏替換，體現功能複用

• 該模式不改變原類文件，不使用繼承，通過對原對象加一層包裝，動態拓展新的功能。在裝飾器中，類只需要關心自己需要添加的功能，而不需要擔心原對象的功能。

  
  
  橋接模式：將抽象部分與實現部分分離，使它們都可以獨立的變化。
  

• 設計原則：遵循單一職責、迪米特、開閉原則，體現功能複用。
• 抽象和實現部分，指的是繼承體系中，接口相同而實現也相同的部分爲抽象部分，而接口相同但實現不同的部分爲實現部分。

• 實現部分的切換非常容易，主要是抽象部分和實現部分耦合很低，使用聚合替換了繼承。

  
  
  組合模式：將對象組合成樹形結構以表示“部分-整體”的層次結構。組合模式使得用戶對單個對象和組合對象的使用具有一致性。
  

• 設計原則：遵循依賴倒置、開閉原則，破壞接口隔離

• 當需求中是體現部分與整體層次的結構時，以及希望用戶忽略組合對象與單個對象的不同，統一使用同一個接口的時候，可以考慮組合模式。
• 缺點：由於節點和分支的功能不一樣，但爲了保持透明性，節點部分功能會無意義。

享元模式：運用共享技術有效地支持大量細粒度的對象

• 設計原則：無
• 享元模式強調內部狀態與外部狀態，內部狀態是可以共享的狀態，外部狀態隨着時間變化而變化。當程序中需要生成大量細粒度的類來表示數據，而其中大部分參數可以看作內部狀態時，可以使用享元模式。

外觀模式：爲子系統的一組接口提供一個一致的界面，此模式定義了一個高層接口，這個接口使得子系統更加容易使用。

- 設計原則：遵循迪米特
- 外觀模式是一種大的宏觀上的模式，它將程序內各個子系統的功能組合起來，提供外觀接口給客戶端，這樣客戶端只需要依賴外觀 接口即可。典型的比如web中sevice根據邏輯組合dao層，api接口

行爲型

觀察者模式：觀察者模式定義了一種一對多的的依賴關係，讓多個觀察者對象同時監聽某一主題對象。這個對象在狀態變化時，會通知所有觀察者對象，使它們能夠自動更新自己。

• 設計原則：遵循迪米特、開閉原則
• 觀察者模式分離了觀察者和被觀察者二者的責任，讓類之間各自維護自己的功能。
• 觀察者模式：發佈（release）–訂閱（subscibe），變化（change）–更新（update）

模板方法模式：定義一個操作中的算法的骨架，而將一些步驟延遲到子類中。模板方法使得子類可以不改變一個算法的結構即可重定義改算法的某些特定步驟。

• 設計原則：破壞里氏替換，體現功能複用
• 通常情況下，模版方法用於定義構建某個對象的步驟與順序，或者定義一個算法的骨架。

命令模式：將一個請求封裝爲一個對象，從而使你可用不同的請求對客戶參數化。

• 設計原則：遵循迪米特，開閉原則
• 命令模式將行爲請求者和行爲實現者解耦，使得命令的添加特別方便，而且易於制定各種命令和利用現有命令組合新的命令。並且可以通過中間的調用者，控制命令的執行情況

狀態模式：當一個對象內在狀態改變時允許改變其行爲，這個對象看起來像是改變了其類。

• 設計原則：遵循單一職責、依賴倒置、開閉原則

職責鏈模式：使多個對象都有機會處理請求，從而避免請求的發送者和接收者之間的耦合關係。將這個對象連成一條鏈，並沿着這條鏈傳遞該請求，直到有一個對象處理它爲止。

• 設計原則：遵循迪米特原則
• 客戶端與具體的處理者解耦，客戶端只認識一個接口，降低了二者的耦合度

解釋器模式

中介者模式：用一個對象來封裝一系列的對象交互。中介者使對象不用顯示地相互引用，從而使其耦合鬆散，而且可以獨立地改變它們的交互。

• 設計原則：遵循迪米特，破壞單一職責
• 中介者模式將一系列對象具有複雜耦合關係的對象集中管理，這些對象往往是多對多的耦合關係，而各個對象也將自己與其他對象的交互行爲委託給中介者，從而減少這些對象之間的耦合關係。

訪問者模式：表示一個作用於某對象結構中的各元素的操作。它使你可以在不改變各元素的類的前提下定義作用於這些元素的新操作。

- 設計原則：
- 訪問者模式將數據結構和作用於結構上的操作相解耦，使得操作集合可以獨立變化，同時添加新的操作或者說訪問者非常容易。這也意味着增加新的數據結構很困難，增加了系統的複雜性。將對各個元素的一組操作行爲集中到了一個訪問者中，其改變不影響系統數據結構。
- 訪問者模式適用於數據結構穩定而算法又易變的系統。

策略模式：策略模式定義了一系列算法，並將每個算法封裝起來，而且使它們還可以相互替換。策略模式讓算法獨立於使用它的客戶端而變化。

• 設計原則：遵循單一職責、依賴倒置、迪米特、開閉原則

備忘錄模式：在不破壞封裝性的前提下，捕獲一個對象的內部狀態，並在該對象之外保存這個狀態。這樣以後就可將該對象恢復到原先保存的狀態。