JAVA設計模式總結之23種設計模式
一、什麼是設計模式
設計模式（Design pattern）是一套被反覆使用、多數人知曉的、經過分類編目的、代碼設計經驗的總結。使用設計模式是為了可重用代碼、讓代碼更容易被他人理解、保證代碼可靠性。 毫無疑問，設計模式於己於他人於系統都是多贏的，設計模式使代碼編制真正工程化，設計模式是軟件工程的基石，如同大廈的一塊塊磚石一樣。項目中合理的運用設計模式可以完美的解決很多問題，每種模式在現在中都有相應的原理來與之對應，每一個模式描述了一個在我們周圍不斷重複發生的問題，以及該問題的核心解決方案，這也是它能被廣泛應用的原因。簡單說：
模式：在某些場景下，針對某類問題的某種通用的解決方案。
場景：項目所在的環境
問題：約束條件，項目目標等
解決方案：通用、可複用的設計，解決約束達到目標。
二、設計模式的三個分類
創建型模式：對象實例化的模式，創建型模式用於解耦對象的實例化過程。
結構型模式：把類或對象結合在一起形成一個更大的結構。
行為型模式：類和對象如何交互，及劃分責任和算法。
如下圖所示：
三、各分類中模式的關鍵點
單例模式：某個類只能有一個實例，提供一個全局的訪問點。
簡單工廠：一個工廠類根據傳入的參量決定創建出那一種產品類的實例。
工廠方法：定義一個創建對象的接口，讓子類決定實例化那個類。
抽象工廠：創建相關或依賴對象的家族，而無需明確指定具體類。
建造者模式：封裝一個複雜對象的構建過程，並可以按步驟構造。
原型模式：通過複製現有的實例來創建新的實例。
適配器模式：將一個類的方法接口轉換成客戶希望的另外一個接口。
組合模式：將對象組合成樹形結構以表示“”部分-整體“”的層次結構。
裝飾模式：動態的給對象添加新的功能。
代理模式：為其他對象提供一個代理以便控制這個對象的訪問。
亨元（蠅量）模式：通過共享技術來有效的支持大量細粒度的對象。
外觀模式：對外提供一個統一的方法，來訪問子系統中的一群接口。
橋接模式：將抽象部分和它的實現部分分離，使它們都可以獨立的變化。
模板模式：定義一個算法結構，而將一些步驟延遲到子類實現。
解釋器模式：給定一個語言，定義它的文法的一種表示，並定義一個解釋器。
策略模式：定義一系列算法，把他們封裝起來，並且使它們可以相互替換。
狀態模式：允許一個對象在其對象內部狀態改變時改變它的行為。
觀察者模式：對象間的一對多的依賴關係。
備忘錄模式：在不破壞封裝的前提下，保持對象的內部狀態。
中介者模式：用一箇中介對象來封裝一系列的對象交互。
命令模式：將命令請求封裝為一個對象，使得可以用不同的請求來進行參數化。
訪問者模式：在不改變數據結構的前提下，增加作用於一組對象元素的新功能。
責任鏈模式：將請求的發送者和接收者解耦，使的多個對象都有處理這個請求的機會。
迭代器模式：一種遍歷訪問聚合對象中各個元素的方法，不暴露該對象的內部結構。
四、概說23種設計模式
1.單例模式
單例模式，它的定義就是確保某一個類只有一個實例，並且提供一個全局訪問點。
單例模式具備典型的3個特點：1、只有一個實例。 2、自我實例化。 3、提供全局訪問點。
因此當系統中只需要一個實例對象或者系統中只允許一個公共訪問點，除了這個公共訪問點外，不能通過其他訪問點訪問該實例時，可以使用單例模式。
單例模式的主要優點就是節約系統資源、提高了系統效率，同時也能夠嚴格控制客戶對它的訪問。也許就是因為系統中只有一個實例，這樣就導致了單例類的職責過重，違背了“單一職責原則”，同時也沒有抽象類，所以擴展起來有一定的困難。其UML結構圖非常簡單，就只有一個類，如下圖：
2.工廠方法模式
作為抽象工廠模式的孿生兄弟，工廠方法模式定義了一個創建對象的接口，但由子類決定要實例化的類是哪一個，也就是說工廠方法模式讓實例化推遲到子類。
工廠方法模式非常符合“開閉原則”，當需要增加一個新的產品時，我們只需要增加一個具體的產品類和與之對應的具體工廠即可，無須修改原有系統。同時在工廠方法模式中用戶只需要知道生產產品的具體工廠即可，無須關係產品的創建過程，甚至連具體的產品類名稱都不需要知道。雖然他很好的符合了“開閉原則”，但是由於每新增一個新產品時就需要增加兩個類，這樣勢必會導致系統的複雜度增加。其UML結構圖：
3.抽象工廠模式
所謂抽象工廠模式就是提供一個接口，用於創建相關或者依賴對象的家族，而不需要明確指定具體類。他允許客戶端使用抽象的接口來創建一組相關的產品，而不需要關係實際產出的具體產品是什麼。這樣一來，客戶就可以從具體的產品中被解耦。它的優點是隔離了具體類的生成，使得客戶端不需要知道什麼被創建了，而缺點就在於新增新的行為會比較麻煩，因為當添加一個新的產品對象時，需要更加需要更改接口及其下所有子類。其UML結構圖如下：
4.建造者模式
對於建造者模式而已，它主要是將一個複雜對象的構建與表示分離，使得同樣的構建過程可以創建不同的表示。適用於那些產品對象的內部結構比較複雜。
建造者模式將複雜產品的構建過程封裝分解在不同的方法中，使得創建過程非常清晰，能夠讓我們更加精確的控制複雜產品對象的創建過程，同時它隔離了複雜產品對象的創建和使用，使得相同的創建過程能夠創建不同的產品。但是如果某個產品的內部結構過於複雜，將會導致整個系統變得非常龐大，不利於控制，同時若幾個產品之間存在較大的差異，則不適用建造者模式，畢竟這個世界上存在相同點大的兩個產品並不是很多，所以它的使用範圍有限。其UML結構圖：
5.原型模式
在我們應用程序可能有某些對象的結構比較複雜，但是我們又需要頻繁的使用它們，如果這個時候我們來不斷的新建這個對象勢必會大大損耗系統內存的，這個時候我們需要使用原型模式來對這個結構複雜又要頻繁使用的對象進行克隆。所以原型模式就是用原型實例指定創建對象的種類，並且通過複製這些原型創建新的對象。
它主要應用與那些創建新對象的成本過大時。它的主要優點就是簡化了新對象的創建過程，提高了效率，同時原型模式提供了簡化的創建結構。UML結構圖：
模式結構
原型模式包含如下角色：
Prototype：抽象原型類
ConcretePrototype：具體原型類
Client：客戶類
6.適配器模式
在我們的應用程序中我們可能需要將兩個不同接口的類來進行通信，在不修改這兩個的前提下我們可能會需要某個中間件來完成這個銜接的過程。這個中間件就是適配器。所謂適配器模式就是將一個類的接口，轉換成客戶期望的另一個接口。它可以讓原本兩個不兼容的接口能夠無縫完成對接。
作為中間件的適配器將目標類和適配者解耦，增加了類的透明性和可複用性。
適配器模式包含如下角色：
Target：目標抽象類
Adapter：適配器類
Adaptee：適配者類
Client：客戶類
7.橋接模式
如果說某個系統能夠從多個角度來進行分類，且每一種分類都可能會變化，那麼我們需要做的就是講這多個角度分離出來，使得他們能獨立變化，減少他們之間的耦合，這個分離過程就使用了橋接模式。所謂橋接模式就是講抽象部分和實現部分隔離開來，使得他們能夠獨立變化。
橋接模式將繼承關係轉化成關聯關係，封裝了變化，完成了解耦，減少了系統中類的數量，也減少了代碼量。
橋接模式包含如下角色：
Abstraction：抽象類
RefinedAbstraction：擴充抽象類
Implementor：實現類接口
ConcreteImplementor：具體實現類
8.組合模式
組合模式組合多個對象形成樹形結構以表示“整體-部分”的結構層次。它定義瞭如何將容器對象和葉子對象進行遞歸組合，使得客戶在使用的過程中無須進行區分，可以對他們進行一致的處理。在使用組合模式中需要注意一點也是組合模式最關鍵的地方：葉子對象和組合對象實現相同的接口。這就是組合模式能夠將葉子節點和對象節點進行一致處理的原因。
雖然組合模式能夠清晰地定義分層次的複雜對象，也使得增加新構件也更容易，但是這樣就導致了系統的設計變得更加抽象，如果系統的業務規則比較複雜的話，使用組合模式就有一定的挑戰了。
模式結構
組合模式包含如下角色：
Component: 抽象構件
Leaf: 葉子構件
Composite: 容器構件
Client: 客戶類
9.裝飾模式
我們可以通過繼承和組合的方式來給一個對象添加行為，雖然使用繼承能夠很好擁有父類的行為，但是它存在幾個缺陷：一、對象之間的關係複雜的話，系統變得複雜不利於維護。二、容易產生“類爆炸”現象。三、是靜態的。在這裡我們可以通過使用裝飾者模式來解決這個問題。
裝飾者模式，動態地將責任附加到對象上。若要擴展功能，裝飾者提供了比繼承更加有彈性的替代方案。雖然裝飾者模式能夠動態將責任附加到對象上，但是他會產生許多的細小對象，增加了系統的複雜度。
模式結構
裝飾模式包含如下角色：
Component: 抽象構件
ConcreteComponent: 具體構件
Decorator: 抽象裝飾類
ConcreteDecorator: 具體裝飾類
10.外觀模式
我們都知道類與類之間的耦合越低，那麼可複用性就越好，如果兩個類不必彼此通信，那麼就不要讓這兩個類發生直接的相互關係，如果需要調用裡面的方法，可以通過第三者來轉發調用。外觀模式非常好的詮釋了這段話。外觀模式提供了一個統一的接口，用來訪問子系統中的一群接口。它讓一個應用程序中子系統間的相互依賴關係減少到了最少，它給子系統提供了一個簡單、單一的屏障，客戶通過這個屏障來與子系統進行通信。通過使用外觀模式，使得客戶對子系統的引用變得簡單了，實現了客戶與子系統之間的鬆耦合。但是它違背了“開閉原則”，因為增加新的子系統可能需要修改外觀類或客戶端的源代碼。
外觀模式包含如下角色：
Facade: 外觀角色
SubSystem:子系統角色
11.亨元模式
在一個系統中對象會使得內存佔用過多，特別是那些大量重複的對象，這就是對系統資源的極大浪費。享元模式對對象的重用提供了一種解決方案，它使用共享技術對相同或者相似對象實現重用。享元模式就是運行共享技術有效地支持大量細粒度對象的複用。系統使用少量對象,而且這些都比較相似，狀態變化小，可以實現對象的多次複用。這裡有一點要注意：享元模式要求能夠共享的對象必須是細粒度對象。享元模式通過共享技術使得系統中的對象個數大大減少了，同時享元模式使用了內部狀態和外部狀態，同時外部狀態相對獨立，不會影響到內部狀態，所以享元模式能夠使得享元對象在不同的環境下被共享。同時正是分為了內部狀態和外部狀態，享元模式會使得系統變得更加複雜，同時也會導致讀取外部狀態所消耗的時間過長。
享元模式包含如下角色：
Flyweight: 抽象享元類
ConcreteFlyweight: 具體享元類
UnsharedConcreteFlyweight: 非共享具體享元類
FlyweightFactory: 享元工廠類
12.代理模式
代理模式就是給一個對象提供一個代理，並由代理對象控制對原對象的引用。它使得客戶不能直接與真正的目標對象通信。代理對象是目標對象的代表，其他需要與這個目標對象打交道的操作都是和這個代理對象在交涉。
代理對象可以在客戶端和目標對象之間起到中介的作用，這樣起到了的作用和保護了目標對象的，同時也在一定程度上面減少了系統的耦合度。
代理模式包含如下角色：
Subject: 抽象主題角色
Proxy: 代理主題角色
RealSubject: 真實主題角色
私我 1 帶走 乾貨