什麼是設計模式？

Christopher Alexander 說過：“每一個模式描述了一個在我們周圍不斷重複發生的問題，以及該問題的解決方案的核心。這樣，你就能一次又一次地使用該方案而不必做重複勞動”。簡單來說就是：

設計模式(Design Pattern)是一套被反覆使用、多數人知曉的、經過分類編目的、程式碼設計經驗的總結，使用設計模式是為了可重用程式碼、讓程式碼更容易被他人理解並且保證程式碼可靠性。

為什麼有設計模式

設計模式開發的規範,最優的方案,選擇合適的模式可大大提高開發效率,少走彎路。如果將設計模式比喻成“三十六計”，那麼每一個模式都是一種計策，它為解決某一類問題而誕生，設計模式能很好的解決一些問題。

設計模式的分類

經典應用框架中常見的設計模式分為三類：

• 建立型模式：對類的例項化過程的抽象。一些系統在建立物件時，需要動態地決定怎樣建立物件，建立哪些物件，以及如何組合和表示這些物件。建立模式描述了怎樣構造和封裝這些動態的決定。包含類的建立模式和物件的建立模式。

常見的建立型模式有：Factory 工廠模式；Singleton 單例模式；Prototype 原型模式

• 結構型模式：描述如何將類或物件結合在一起形成更大的結構。分為類的結構模式和物件的結構模式。類的結構模式使用繼承把類，介面等組合在一起，以形成更大的結構。類的結構模式是靜態的。物件的結構模式描述怎樣把各種不同型別的物件組合在一起，以實現新的功能的方法。物件的結構模式是動態的。

常見的結構型模式有：Adapter 介面卡模式；Decorator 裝飾器模式；Proxy 代理模式

• 行為型模式：對在不同的物件之間劃分責任和演算法的抽象化。不僅僅是關於類和物件的，並是關於他們之間的相互作用。類的行為模式使用繼承關係在幾個類之間分配行為。物件的行為模式則使用物件的聚合來分配行為。

常見的行為型模式有：Strategy 策略模式；Template 模板模式；Delegate 委派模式；Observer 觀察者模式

設計模式使用頻率排行

注意：在常用的23種設計模式中其實面沒有委派模式（Delegate）的影子，但是在Spring中委派模式確實用的比較多的一種模式，Spring MVC框架中的DispatcherServlet其實就用到了委派模式。

單例模式(Singleton)

單例模式：Singleton的作用是保證在應用程式中，一個類Class只有一個例項存在。並提供全域性訪問。Singleton限制了例項個數，有利於GC的回收。

策略模式(Strategy)

策略模式：策略模式針對一組演算法，將每一個演算法封裝到具有共同介面的獨立的類中，從而使得它們可以相互替換。策略模式使得演算法可以在不影響到客戶端的情況下發生變化。策略模式把行為和環境分開。環境類負責維持和查詢行為類，各種演算法在具體的策略類中提供。由於演算法和環境獨立開來，演算法的增減，修改都不會影響到環境和客戶端。

原型模式(Prototype)

原型模式：通過給出一個原型物件來指明所要建立的物件的型別，然後用複製這個原型物件的方法創建出更多同類型的物件。原始模型模式允許動態的增加或減少產品類，產品類不需要非得有任何事先確定的等級結構，原始模型模式適用於任何的等級結構。缺點是每一個類都必須配備一個克隆方法

因為Java中的提供clone()方法來實現物件的克隆，所以Prototype模式實現一下子變得很簡單。

工廠模式（Factory）

工廠模式：定義一個用於建立物件的介面，讓介面子類通過工廠方法決定例項化哪一個類。

裝飾模式（Decorator）

裝飾模式：裝飾模式以對客戶端透明的方式擴充套件物件的功能，是繼承關係的一個替代方案，提供比繼承更多的靈活性。動態給一個物件增加功能，這些功能可以再動態的撤消。增加由一些基本功能的排列組合而產生的非常大量的功能。

使用Decorator的理由是：這些功能需要由使用者動態決定加入的方式和時機。Decorator提供了"即插即用"的方法，在執行期間決定何時增加何種功能。

介面卡模式（Adapter）

介面卡模式：把一個類的介面變換成客戶端所期待的另一種介面，從而使原本因介面原因不匹配而無法一起工作的兩個類能夠一起工作。適配類可以根據引數返還一個合適的例項給客戶端
將兩個不相容的類糾合在一起使用，屬於結構型模式，需要Adaptee(被適配者)和Adaptor(介面卡)兩個身份。

為何使用?
我們經常碰到要將兩個沒有關係的類組合在一起使用，第一解決方案是：修改各自類的介面，但是如果我們沒有原始碼，或者，我們不願意為了一個應用而修改各自的介面。 怎麼辦? 使用Adapter，在這兩種介面之間建立一個混合介面(混血兒)。

如何使用?
實現Adapter方式，其實"think in Java"的"類再生"一節中已經提到，有兩種方式：組合(composition)和繼承(inheritance)。

代理模式（Proxy）

代理模式：代理模式給某一個物件提供一個代理物件，並由代理物件控制對源物件的引用。代理就是一個人或一個機構代表另一個人或者一個機構採取行動。

某些情況下，客戶不想或者不能夠直接引用一個物件，代理物件可以在客戶和目標物件直接起到中介的作用。客戶端分辨不出代理主題物件與真實主題物件。代理模式可以並不知道真正的被代理物件，而僅僅持有一個被代理物件的介面，這時候代理物件不能夠建立被代理物件，被代理物件必須有系統的其他角色代為建立並傳入。

觀察者模式（Observer）

觀察者模式：觀察者模式定義了一種一隊多的依賴關係，讓多個觀察者物件同時監聽某一個主題物件。這個主題物件在狀態上發生變化時，會通知所有觀察者物件，使他們能夠自動更新自己。釋出訂閱。

模板模式（Template）

模板模式：模板方法模式準備一個抽象類，將部分邏輯以具體方法以及具體構造子的形式實現，然後宣告一些抽象方法來迫使子類實現剩餘的邏輯。

不同的子類可以以不同的方式實現這些抽象方法，從而對剩餘的邏輯有不同的實現。先制定一個頂級邏輯框架，而將邏輯的細節留給具體的子類去實現。

關於設計模式的一點總結

設計上的事就是這樣，想到了， 就能比較優雅的解決問題，想不到的話， 就只能使用到處修改程式碼的方法比較笨拙的應對問題，還容易將專案弄的混亂。當然也建議你們看看這套關於設計模式視訊，放在群895244712裡面 或許會給你們一些啟發。

現在我比較慶幸當初學習了設計模式，而沒有聽其他人的“建議”：我們做的專案中用不到設計模式，學這個沒用。設計模式是個好東西，以後肯定還要進一步的學習，並且在專案中多實踐，提升自己的設計能力。

其實設計模式並不難，難的是真正領悟它的精妙，並且能靈活的運用於日常專案的開發。