設計模式總結(jié)
現(xiàn)在關于24種設計模式都介紹完了，其中包括GOF提出的23種設計模式和簡單工廠模式。每種模式都有一個案例，可能不是每個案例都是這么的貼切、真實，同時每個模式最后都盡量舉出了框架中涉及到的代碼進行解析，這對于理解每種設計模式還是很有幫助的，下面對這24種模式進行簡單的總結(jié)。
創(chuàng)建型模式
| 模式名稱 | 總結(jié) |
|---|---|
| 簡單工廠模式 | 簡單工廠模式提供了專門的工廠類用于創(chuàng)建對象，將對象的創(chuàng)建和對象的使用分離開 |
| 工廠方法模式 | 工廠方法模式是簡單工廠模式的延伸，工廠方法模式定義一個創(chuàng)建產(chǎn)品對象的工廠接口，將實際創(chuàng)建工作推遲到子類中 |
| 抽象工廠模式 | 抽象工廠模式是工廠方法模式的進一步延伸，是工廠方法的升級，為創(chuàng)建一組相關或相互依賴的對象提供一個接口，而且無須指定它們的具體類 |
| 單例模式 | 單例模式是一種目標明確、結(jié)構簡單、理解容易的設計模式，一個類只有一個實例，而且自行實例化并向整個系統(tǒng)提供這個實例 |
| 原型模式 | 原型管理器(Prototype Manager)是將多個原型對象存儲在一個集合中供客戶端使用，它是一個專門負責克隆對象的工廠，其中定義了一個集合用于存儲原型對象，如果需要某個原型對象的一個克隆，可以通過復制集合中對應的原型對象來獲得 |
| 建造者模式 | 建造者模式的核心在于如何一步步構建一個包含多個組成部件的完整對象，使用相同的構建過程構建不同的產(chǎn)品 |
以上都屬于創(chuàng)建型模式，因此這些模式都針對對象的創(chuàng)建和管理等方面來設計的。其中，單例模式和原型模式非常容易理解，單例模式是在內(nèi)存中保持只有一個對象，原型模式是通過復制的方式產(chǎn)生一個新的對象。而工廠方法模式、抽象工廠模式和建造者模式具有較多的相似性，它們之間的區(qū)別如下：
工廠方法模式注重的是整體對象的創(chuàng)建方法。
建造者模式注重的是部件構建的過程，旨在通過一步步精確構造，創(chuàng)建出一個復雜的對象。
抽象工廠模式實現(xiàn)對產(chǎn)品家族的創(chuàng)建，抽象工廠模式不關心構建過程，只關心什么產(chǎn)品由什么工廠生產(chǎn)即可。
結(jié)構型模式
| 模式名稱 | 總結(jié) |
|---|---|
| 適配器模式 | 適配器模式將現(xiàn)有接口轉(zhuǎn)化為客戶類所期望的接口，實現(xiàn)了對現(xiàn)有類的復用 |
| 橋接模式 | 橋接模式為多維度變化的系統(tǒng)提供了一套完整的解決方案，將抽象和實現(xiàn)解耦，使得兩者可以獨立的變化，并且降低了系統(tǒng)的復雜度 |
| 組合模式 | 組合模式使用面向?qū)ο蟮乃枷雭韺崿F(xiàn)樹形結(jié)構的構建與處理，將對象組合成樹形結(jié)構以表示“部分-整體”的層次結(jié)構，使得用戶對單個對象和組合對象的使用具有一致性 |
| 裝飾模式 | 裝飾模式降低了系統(tǒng)的耦合度，可以動態(tài)增加或刪除對象的職責，并使得需要裝飾的具體構件類和具體裝飾類可以獨立變化，以便增加新的具體構件類和具體裝飾類 |
| 外觀模式 | 外觀模式通過引入一個外觀角色來簡化客戶端與子系統(tǒng)之間的交互，為復雜的子系統(tǒng)調(diào)用提供一個統(tǒng)一的入口，使子系統(tǒng)與客戶端的耦合度降低，且客戶端調(diào)用非常方便 |
| 享元模式 | 當系統(tǒng)中存在大量相同或者相似的對象時，享元模式是一種較好的解決方案，它通過共享技術實現(xiàn)相同或相似的細粒度對象的復用，從而節(jié)約了內(nèi)存空間，提高了系統(tǒng)性能 |
| 代理模式 | 代理模式是常用的結(jié)構型設計模式之一，它為對象的間接訪問提供了一個解決方案，可以對對象的訪問進行控制 |
上面的結(jié)構型模式都是通過組合類或?qū)ο螽a(chǎn)生更復雜的結(jié)構以適應更高層次的邏輯需求。其中代理模式、裝飾模式和適配器模式比較相似，這三個模式有一個共同點，它們都能夠?qū)︻愡M行“包裝”，但它們之間的主要區(qū)別如下：
裝飾模式是代理模式的一個特殊應用，雖然它們都具有相同的接口，但裝飾模式是對類的功能進行加強或減弱，重點是類的功能變化；而代理模式著重代理過程的控制。
裝飾模式和適配器模式都能對類進行“包裝”，但裝飾模式包裝的是同一家族（相同接口或父類）的對象，而適配器模式可以修飾不同接口的對象，主要是將非本家族的對象偽裝成同一家族對象。
行為型模式
| 模式名稱 | 總結(jié) |
|---|---|
| 職責鏈模式 | 職責鏈模式通過建立一條鏈來組織請求的處理者，請求將沿著鏈進行傳遞，請求發(fā)送者無須知道請求在何時、何處以及如何被處理，實現(xiàn)了請求發(fā)送者與處理者的解耦 |
| 命令模式 | 命令模式可以將請求發(fā)送者與接收者解耦，請求發(fā)送者通過命令對象來間接引用請求接收者 |
| 解釋器模式 | 解釋器模式為自定義語言的設計和實現(xiàn)提供了一種解決方案，它用于定義一組文法規(guī)則并通過這組文法規(guī)則來解釋語言中的句子 |
| 迭代器模式 | 迭代器模式通過引入迭代器可以將數(shù)據(jù)的遍歷功能從聚合對象中分離出來，聚合對象只負責存儲數(shù)據(jù)，而遍歷數(shù)據(jù)由迭代器來完成 |
| 中介者模式 | 中介者模式將一個網(wǎng)狀的系統(tǒng)結(jié)構變成一個以中介者對象為中心的星形結(jié)構，在這個星型結(jié)構中，使用中介者對象與其他對象的一對多關系來取代原有對象之間的多對多關系 |
| 備忘錄模式 | 備忘錄是一個很特殊的對象，它在不破壞封裝性的前提下，捕獲一個對象的內(nèi)部狀態(tài)，并在該對象之外保存這個狀態(tài)。這樣以后就可以將該對象恢復到原先保存的狀態(tài) |
| 觀察者模式 | 觀察者模式定義對象間一種一對多的依賴關系，使得每當一個對象改變狀態(tài)，則所有依賴于它的對象都會得到通知并被自動更新 |
| 狀態(tài)模式 | 狀態(tài)模式將一個對象在不同狀態(tài)下的不同行為封裝在一個個狀態(tài)類中，通過設置不同的狀態(tài)對象可以讓環(huán)境對象擁有不同的行為，而狀態(tài)轉(zhuǎn)換的細節(jié)對于客戶端而言是透明的，方便了客戶端的使用 |
| 策略模式 | 策略模式定義一組算法，將每個算法都封裝起來，并且使它們之間可以互換 |
| 模板方法模式 | 模板方法模式定義一個操作中的算法的框架，而將一些步驟延遲到子類中，使得子類可以不改變一個算法的結(jié)構即可重定義該算法的某些特定步驟 |
| 訪問者模式 | 當系統(tǒng)中存在一個較為復雜的對象結(jié)構，且不同訪問者對其所采取的操作也不相同時，可以考慮使用訪問者模式進行設計。 |
行為型模式的個數(shù)最多高達11個，其中命令模式和策略模式的類圖很相似，命令模式比策略模式多了一個接收者角色，它們之間的區(qū)別如下：
策略模式是封裝算法，認為算法是一個完整的、不可拆分的原子業(yè)務，其目的是讓這些算法獨立，并且可以相互替換，讓行為的變化獨立于擁有行為的客戶。
命令模式則是對動作的解耦，把一個動作的執(zhí)行分為執(zhí)行對象（接受者角色）、執(zhí)行行為（命令角色），讓兩者相互獨立而互不影響。
結(jié)語
至此，設計模式的學習可以說告一段落了。但是學會如何在代碼中靈活運用這些模式還有很長的路要走，不代表到此就停止了，學以致用才是最終的目的，希望自己在以后的編程生涯中對此銘記于心，共勉。
