設計模式——設計模式總結

     設計模式總結

      設計模式（Design Patterns）是可複用面向對象軟件的基礎，是一套被反覆使用、多數人知曉的、通過分類編目的、代碼設計經驗的總結。使用設計模式是爲了可重用代碼，讓代碼更容易被他人理解、保證代碼可靠性。 毫無疑問，設計模式於己於他人於系統都是多贏的，設計模式使代碼編制真正工程化，設計模式是軟件工程的基石，如同大廈的一塊塊磚石同樣。項目中合理的運用設計模式能夠完美的解決不少問題，每種模式在如今中都有相應的原理來與之對應，每個模式描述了一個在咱們周圍不斷重複發生的問題，以及該問題的核心解決方案，這也是它能被普遍應用的緣由。

 

一. 首先看看設計模式的分類：

整體來講設計模式分爲三大類：

建立型模式，共五種：工廠方法模式、抽象工廠模式、單例模式、建造者模式、原型模式。

結構型模式，共七種：適配器模式、裝飾器模式、代理模式、外觀模式、橋接模式、組合模式、享元模式。

行爲型模式，共十一種：策略模式、模板方法模式、觀察者模式、迭代器模式、責任鏈模式、命令模式、備忘錄模式、狀態模式、訪問者模式、中介者

模式、解釋器模式。

其餘模式：併發型模式和線程池模式。

二. 設計模式中用到的設計原則

1.開閉原則（Open Close Principle）

      開閉原則說的是對擴展開放，對修改關閉。按照開閉原則在程序代碼須要進行擴展的時候不能對原有的程序進行修改而是要對程序實現熱插拔的效果。

這樣一來程序的易複用和可擴展性就能獲得大大提高。

2.里氏代換原則（Liskov Substitution Principle）

      里氏代換原則（LSP）中說，任何基類出現的地方，子類必定能夠出現。LSP是繼承複用的基石，只有當擴展類能夠替換掉基類，軟件的單位不受到影響

時，基類才能真正的被複用，而擴展類也可以在基類的基礎上增長新的行爲。LSP是開閉原則的補充。實現開閉原則的關鍵步驟就是抽象化。而基類與

擴展類的繼承關係就是抽象化的具體實現。因此LSP是對實現抽象化的具體步驟的規範。

3. 依賴倒轉原則（Dependence Inversion Principle）

      依賴倒轉原則是開閉原則的基礎，具體是說要針對接口編程而不是針對具體實現編程。爲交互對象之間的鬆耦合設計而努力。

4. 接口隔離原則（Interface Segregation Principle）

      接口隔離原則是說要使用多個隔離的接口，而不要使用單個接口。其做用是下降對象之間的耦合度。

5. 迪米特法則（Demeter Principle）

      迪米特法則也叫最少知道原則。意思是對象之間應該儘可能少的知道對方的信息。使得對象之間在必定程度上是相對獨立的，做用也是下降對象之間的依

賴程度。

6. 合成複用原則（Composite Reuse Principle）

意思就是多用組合少用繼承。 更加靈活易於變化。

設計模式原則小結：

其實以上提到的各類原則目標大概只有一個：下降對象之間的耦合，增長程序的可複用性、可擴展性、可維護性。設計模式就是軟件設計的一種思想，

從大型軟件架構出發，爲了可複用和可升級而努力。

三. 經常使用的23中設計模式

1. 策略模式（Strategy Pattern）

      策略模式封裝了一系列的算法策略族，這些策略是獨立於客戶的，而且這些策略是能夠互換的。客戶經過上下文交互類就能夠只調用一個執行策略方法

就能夠調用任何一個策略的實現而且能夠在不一樣的策略之間切換。

對策略模式的詳細介紹：

http://www.cnblogs.com/wxisme/p/4497535.html

2. 工廠模式 （Factory Pattern）

      工廠模式有3種。簡單工廠模式、工廠方法模式、抽象工廠模式。

簡單工廠模式：

      簡單工廠模式也叫靜態工廠模式，工廠類通常使用靜態方法 經過接收的參數不一樣來返回不一樣的對象實例。可是對增長新產品無能爲力，不增長代碼沒法擴展。

工廠方法模式：

      避免了簡單工廠的缺點，知足了OCP（開閉原則，對擴展開放，對修改關閉）原則。簡單工廠只有一個工廠類，而工廠方法有一組實現了相同接口的工廠方法。

工廠方法模式的缺點：結構和代碼複雜度高，可是可擴展性好，客戶端編程難度小。綜合考慮，簡單工廠模式，簡單有必定的

可擴展性。實際上簡單工廠模式用的多。

抽象工廠模式：

      抽象工廠模式能夠增長產品族，可是不能夠增長新產品。縱向擴展。抽象工廠模式的用意爲：給客戶端提供一個接口，能夠建立多個產

品族中的產品對象。 關於工廠模式的詳細介紹：

http://www.cnblogs.com/wxisme/p/4518599.html

http://www.cnblogs.com/poissonnotes/archive/2010/12/01/1893871.html

3. 單例模式 （Singleton Pattern）

      單例模式保證了一個類在同一時間內JVM中只有一個實例化對象存在。單例模式確保一個類只有一個實例，並只提供一個全局訪問點。單例模式的意義

在於它能夠保證只有一個實例化對象，在必定狀況下能夠下降系統開銷，對於只能有一個實例的類來講保證了系統的穩定性和安全性。

單例模式的實現方式主要有：餓漢式、懶漢式、雙重檢測鎖、靜態內部類、枚舉。

關於單例模式的具體實現和詳細介紹：

http://www.cnblogs.com/wxisme/p/4517343.html

4. 建造者模式 （Constructor Pattern）

      工廠類模式提供的是建立單個類的模式，而建造者模式則是將各類產品集中起來進行管理，用來建立複合對象，所謂複合對象就是指某個類具備不一樣的

屬性。建造者模式的意義在於實現了構建和裝配的解耦，實現了構建算法和裝配算法的解耦，使用於構建過程複雜的狀況。

關於建造者模式的例子：

http://www.cnblogs.com/wxisme/p/4520998.html

5. 原型模式 （Prototype Pattern）

原型模式只要用來實現對象的複製，對於建立或者複製一個對象的實例很是複雜的時候就可使用原型模式來拷貝。在一個複雜的對象中每每還有其餘

的對象屬性，這樣若是直接複製將致使兩個對象中的對象屬性其實是指向同一個屬性實例的。這就須要進行深度克隆。實現深度克隆的方法有兩種一

種是實現Cloneable接口，重寫clone()方法，另外一種是經過序列化反序列化來獲取對象的拷貝。

關於原型模式的例子：

http://www.cnblogs.com/wxisme/p/4540634.html

6. 適配器模式 （Adaptor  Pattern）

      適配器模式將一個接口轉換成客戶指望的另外一個接口，目的是次消除因爲接口不匹配致使的兼容性問題。主要分爲三類：類的適配器模式、對象的適配

器模式、接口的適配器模式。適配器也能夠說成接口與接口之間的轉換器。適配器的一個典型的應用是：JavaIO中的轉換流，能夠將字節流轉換成字符

流，是流的適配器。

關於適配器模式的例子：

http://www.cnblogs.com/wxisme/p/4522632.html

7. 裝飾模式 （Decorator Pattern）

       裝飾器模式：動態地給一個對象添加一些額外的職責或者行爲。就增長功能來講， Decorator模式相比生成子類更爲靈活。裝飾器模式提供了改變子類

的靈活方案。裝飾器模式在沒必要改變原類文件和使用繼承的狀況下，動態的擴展一個對象的功能。它是經過建立一個包裝對象，也就是裝飾來包裹真實的對象。

使用裝飾器模式，能夠避免代碼重複和具體子類數量的增長。

關於裝飾模式的例子與解釋：

http://www.cnblogs.com/wxisme/p/4510852.html

8. 代理模式 （Proxy Pattern）

      代理模式是經常使用的java設計模式，他的特徵是代理類與委託類有一樣的接口，代理類主要負責爲委託類預處理消息、過濾消息、把消息轉發給委託類，

以及過後處理消息等。代理類與委託類之間一般會存在關聯關係，一個代理類的對象與一個委託類的對象關聯，代理類的對象自己並不真正實現服務，而是

經過調用委託類的對象的相關方法，來提供特定的服務。 按照代理的建立時期，代理類能夠分爲兩種。 靜態代理：由程序員建立或特定工具自動生成源代碼，再對其編譯。在程序運行前，代理類的.class文件就已經存在了。 動態代理：在程序運行時，運用反射機制動態建立而成。 

更多介紹：

http://www.cnblogs.com/wxisme/p/4550574.html

9.外觀模式 （Facade Pattern）

 外觀模式提供了一個統一的接口，用來訪問子系統中的一羣接口。外觀定義了一個高層接口，讓子系統更容易使用。簡單的說，外觀模式就是把複雜

的系統的具體操做封裝起來，只暴露一個簡單的接口，作和衆多子系統之間鬆耦合。外觀模式是爲了解決類與類之家的依賴關係的，像spring同樣，可

以將類和類之間的關係配置到配置文件中，而外觀模式就是將他們的關係放在一個Facade類中，下降了類類之間的耦合度。

關於外觀模式的例子：

http://www.cnblogs.com/wxisme/p/4541085.html

10.橋接模式（Bridge Pattern）

      橋接模式就是把事物和其具體實現分開，使他們能夠各自獨立的變化。橋接的用意是：將抽象化與實現化解耦，使得兩者能夠獨立變化。這樣一來兩個

維度之間就能夠任意的擴展和變化而不影響對方。橋接模式極大的提升了系統的可擴展性，能夠大大下降維護的成本。

關於橋接模式：

http://www.cnblogs.com/wxisme/p/4553362.html

11. 享元模式（Flyweight Pattern）

      享元模式的主要目的是實現對象的共享，即共享池，當系統中對象多的時候能夠減小內存的開銷，一般與工廠模式一塊兒使用。FlyWeightFactory負責創

建和管理享元單元，當一個客戶端請求時，工廠須要檢查當前對象池中是否有符合條件的對象，若是有，就返回已經存在的對象，若是沒有，則建立一

個新對象，FlyWeight是超類。一提到共享池，咱們很容易聯想到Java裏面的JDBC鏈接池，想一想每一個鏈接的特色，咱們不難總結出：適用於做共享的一

些個對象，他們有一些共有的屬性，就拿數據庫鏈接池來講，url、driverClassName、username、password及dbname，這些屬性對於每一個鏈接

來講都是同樣的，因此就適合用享元模式來處理，建一個工廠類，將上述類似屬性做爲內部數據，其它的做爲外部數據，在方法調用時，當作參數傳進

來，這樣就節省了空間，減小了實例的數量。

關於享元模式的例子：

http://www.cnblogs.com/wxisme/p/4549858.html

12. 模板方法模式（Template Method Pattern）

      模板方法模式是編程中常常用到的模式，它定義了一個操 做中的算法骨架，將某些步驟延遲到子類中實現。這樣，新的子類能夠在 不改變一個算法

結構的前提下從新定義該算法的某些特定的步驟。處理某個流程的代碼已經都具有，可是其中某個節點的代碼暫時不 能肯定。所以採用工廠方法模式

將這個節點的代碼實現轉移給子類完成 即：處理步驟父類中定義好，具體實現延遲到子類中定義。 模板方法模式的使用場景：實現一個算法時，整

體步驟很固定。可是某些部分易變。易變部分能夠抽象出來，供子類實現。

模板方法模式的具體例子：

http://www.cnblogs.com/wxisme/p/4540600.html

13. 觀察者模式（Observer Pattern）

      觀察者模式定義了對象之間的一對多的依賴，這樣一來，當一個狀態發生變化時，它的全部依賴者都會收到通知並自動更新。；相似於郵件的訂閱同樣

當一個用戶訂閱了某個主題時，每當主題有變化或者更新的時候都會通知訂閱的用戶，固然這種訂閱能夠註冊也能夠註銷。一樣和電子郵件同樣，訂閱

也有推送式和拉取式，就像SMTP協議和POP3協議同樣。

關於觀察者模式的例子：

http://www.cnblogs.com/wxisme/p/4499147.html

14. 迭代器模式（Iterator Pattern）

      迭代器模式很是好理解就是提供一種功能來遍歷一個集合容器，無論是C++仍是Java都在集合容器裏提供了一種遍歷各類容器的迭代器，Java中還內置

了Iterator接口。

關於迭代器模式的例子：

http://www.cnblogs.com/wxisme/p/4541008.html

15. 責任鏈模式（Chain of Responsibility）

      責任鏈模式是一種對象的行爲模式。在責任鏈模式裏，不少對象由每個對象對其下家的引用而鏈接起來造成一條鏈。請求在這個鏈上傳遞，直到鏈上

的某一個對象決定處理此請求。發出這個請求的客戶端並不知道鏈上的哪一個對象最終處理這個請求，這使得系統能夠在不影響客戶端的狀況下動態地

從新組織和分配責任。說到責任鏈模式我想到了多功能的鏈表，還有DNS的遞歸解析方式。好像都是責任鏈。

責任鏈的例子：

http://www.cnblogs.com/wxisme/p/4550712.html

16. 命令模式（Command Pattern）

命令模式就是將一個請求封裝爲一個對象，從而使咱們能夠用不一樣的請求對客戶進行參數化，對請求排隊或者記錄請求日誌，以及支持可撤銷的操做。

也稱之爲：動做模式，事務模式。簡單的說命令模式將命令的發出者、命令的傳遞者、命令的執行者獨立出來，知足了鬆耦合的要求，易於維護和更改。

命令模式的例子：

http://www.cnblogs.com/wxisme/p/4540588.html

17. 備忘錄模式（Memento Pattern）

      備忘錄對象是一個用來存儲另一個對象內部狀態的快照的對象。備忘錄模式的用意是在不破壞封裝的條件下，將一個對象的狀態捕捉(Capture)住，

並外部化，存儲起來，從而能夠在未來合適的時候把這個對象還原到存儲起來的狀態。備忘錄模式經常與命令模式和迭代子模式一同使用。簡單的說備

忘錄模式就是在必要的時候能夠恢復到對象的某一個狀態。對對象的備忘其實就是對這個對象某個狀態的深度拷貝。這讓我想起了原型模式。等等我還

想起了DBMS中事務的撤銷和數據恢復還有DBMS的日誌備份系統。

關於備忘錄模式的例子：

http://www.cnblogs.com/wxisme/p/4540682.html

18. 狀態模式（State Pattern）

狀態模式，又稱狀態對象模式（Pattern of Objects for States），狀態模式是對象的行爲模式。狀態模式容許一個對象在其內部狀態改變的時候改

變其行爲。這個對象看上去就像是改變了它的類同樣。狀態模式可讓對象在不一樣的狀態之間切換，而且隨着對象狀態的改變其行爲也跟着改變。

關於狀態模式的例子：

http://www.cnblogs.com/wxisme/p/4544432.html

19. 訪問者模式（Visitor Pattern）

訪問者模式把數據結構和做用於結構上的操做解耦合，使得操做集合可相對自由地演化。訪問者模式適用於數據結構相對穩定算法又易變化的系統。因

爲訪問者模式使得算法操做增長變得容易。若系統數據結構對象易於變化，常常有新的數據對象增長進來，則不適合使用訪問者模式。訪問者模式的優

點是增長操做很容易，由於增長操做意味着增長新的訪問者。訪問者模式將有關行爲集中到一個訪問者對象中，其改變不影響系統數據結構。其缺點就

是增長新的數據結構很困難。

訪問者模式的詳細介紹：

http://www.cnblogs.com/java-my-life/archive/2012/06/14/2545381.html

20. 中介者模式（Mediator Pattern）

      中介者模式是對象的行爲模式。中介者模式包裝了一系列對象相互做用的方式，使得這些對象沒必要相互明顯引用。從而使它們能夠較鬆散地耦合。當

這些對象中的某些對象之間的相互做用發生改變時，不會當即影響到其餘的一些對象之間的相互做用。從而保證這些相互做用能夠彼此獨立地變化。中介

者模式就是把對象之間的複雜網狀關聯結構化解成星形結構使得對象之間解耦。

關於中介者模式的詳細舉例：

http://www.cnblogs.com/wxisme/p/4546723.html

http://www.cnblogs.com/java-my-life/archive/2012/06/20/2554024.html

21. 解釋器模式（Interpreter Pattern）

     解釋器模式是類的行爲模式。給定一個語言以後，解釋器模式能夠定義出其文法的一種表示，並同時提供一個解釋器。客戶端可使用這個解釋器來解

釋這個語言中的句子。解釋器模式在大多數狀況下是用不到的。解釋器模式中有一個Context上下文類用來獲取要解析語句的輸入流。每一個表達式類中

有一個interpret(Context c)方法用來解析語句的語義並返回正確的結果。

關於解釋器模式請看：

http://www.cnblogs.com/java-my-life/archive/2012/06/19/2552617.html

22. 組合模式（Composite Pattern）

組合模式，將對象組合成樹形結構以表示「部分-總體」的層次結構，組合模式使得用戶對單個對象和組合對象的使用具備一致性。有時候又叫作部分

-總體模式，它使咱們樹型結構的問題中，模糊了簡單元素和複雜元素的概念，客戶程序能夠像處理簡單元素同樣來處理複雜元素,從而使得客戶程序

與複雜元素的內部結構解耦。組合模式讓你能夠優化處理遞歸或分級數據結構。有許多關於分級數據結構的例子，使得組合模式很是有用武之地。關於

分級數據結構的一個廣泛性的例子是你每次使用電腦時所遇到的:文件系統。文件系統由目錄和文件組成。每一個目錄均可以裝內容。目錄的內容能夠是

文件，也能夠是目錄。按照這種方式，計算機的文件系統就是以遞歸結構來組織的。若是你想要描述這樣的數據結構，那麼你可使用組合模式。

組合模式請看：

http://www.cnblogs.com/wxisme/p/4692637.html

小結：

      各類設計模式應該是常常組合起來用的而並非單獨使用。只有在適合的場景下把合適的設計模式組合起來才能發揮其巨大威力。可是也要注意過分的

使用設計模式可能致使代碼被過分工程化。用該老是用最簡單的解決方案完成工做，並在真正須要的地方使用。 其餘的設計模式還有：架構模式、領域特定模式、業務流程模式、用戶界面設計模式、反模式等等，並非用到了哪一個設計模式就要按照它固有的格式來用，這個要看具體的場景，靈活而準確的用好設計模式非一日之功啊，需要不斷的去積累經驗。在前進的路上。。。

      如今23種設計模式複習完畢（抽象工廠模式歸到工廠模式中），具體的示例和每一種設計模式的用法和特色請參考個人博客：設計模式。

 

      他山之石 ：

      設計模式總結 ：

      http://blog.csdn.net/xtwolf008/article/details/8807006

      設計模式專題 ：

      http://zzk.cnblogs.com/s?w=blog%3Ajava-my-life+Java%E4%B8%8E%E6%A8%A1%E5%BC%8F&t=

 

      若有錯誤請指正：）

      如要引用請指明出處：http://www.cnblogs.com/wxisme/p/4693094.html