Java設計模式-概述

  設計模式（Design Pattern）是一套被反複使用、多數人知曉的、經過分類的、代碼設計經驗的總結。

  使用設計模式的目的：為了代碼可重用性、讓代碼更容易被他人了解、保證代碼可靠性。 設計模式使代碼編寫真正工程化；設計模式是軟體工程的基石脈絡，如同大廈的結構一樣。

  使用設計模式是為了重用代碼、讓代碼更容易被他人了解、保證代碼可靠性。 毫無疑問，設計模式于己于他人于系統都是多赢的，設計模式使代碼編制真正工程化，設計模式是軟體工程的基石，如同大廈的一塊塊磚石一樣。項目中合理地運用設計模式可以完美地解決很多問題，每種模式在現實中都有相應的原理來與之對應，每種模式都描述了一個在我們周圍不斷重複發生的問題，以及該問題的核心解決方案，這也是設計模式能被廣泛應用的原因。

  設計模式（Design pattern）代表了最佳的實踐，通常被有經驗的面向對象的軟體開發人員所采用。設計模式是軟體開發人員在軟體開發過程中面臨的一般問題的解決方案。這些解決方案是衆多軟體開發人員經過相當長的一段時間的試驗和錯誤總結出來的。

設計模式的原則

總原則：開閉原則（Open Close Principle）

  開閉原則就是說對擴充開放，對修改關閉。

  在程式需要進行拓展的時候，不能去修改原有的代碼，實作一個熱插拔的效果。是以一句話概括就是：為了程式的擴充性好，易于維護和更新

單一職責原則（Single Responsibility Principle）

  不要存在多于一個導緻類變更的原因，也就是說每個類應該實作單一的職責，如若不然，就應該把類拆分。

裡氏代換原則（Liskov Substitution Principle）

  裡氏代換原則（Liskov Substitution Principle LSP）面向對象設計的基本原則之一。裡氏代換原則中說，任何基類可以出現的地方，子類一定可以出現。 LSP是繼承複用的基石，隻有當衍生類可以替換掉基類，軟體機關的功能不受到影響時，基類才能真正被複用，而衍生類也能夠在基類的基礎上增加新的行為。裡氏代換原則是對“開-閉”原則的補充。實作“開-閉”原則的關鍵步驟就是抽象化。而基類與子類的繼承關系就是抽象化的具體實作，是以裡氏代換原則是對實作抽象化的具體步驟的規範。—— From Baidu 百科

依賴倒轉原則（Dependence Inversion Principle）

  這個是開閉原則的基礎，具體内容：真對接口程式設計，依賴于抽象而不依賴于具體。

接口隔離原則（Interface Segregation Principle）

  這個原則的意思是：使用多個隔離的接口，比使用單個接口要好。還是一個降低類之間的耦合度的意思，從這兒我們看出，其實設計模式就是一個軟體的設計思想，從大型軟體架構出發，為了更新和維護友善。是以上文中多次出現：降低依賴，降低耦合。

迪米特法則（最少知道原則）（Demeter Principle）

  為什麼叫最少知道原則，就是說：一個實體應當盡量少的與其他實體之間發生互相作用，使得系統功能子產品相對獨立。

合成複用原則（Composite Reuse Principle）

  原則是盡量使用合成/聚合的方式，而不是使用繼承。

  總結來說就是找出應用中可能需要變化之處，把它們獨立出來，不要和那些不需要變化的代碼混在一起；針對接口程式設計，而不是針對實作程式設計；為了互動對象之間的松耦合設計而努力。

設計模式

  設計模式的三個分類： 建立型模式、結構型模式、行為型模式。

建立型模式

  建立型模式：對象執行個體化的模式，建立型模式用于解耦對象的執行個體化過程。主要關注點是“怎樣建立對象？”，它的主要特點是“将對象的建立與使用分離”。這樣可以降低系統的耦合度，使用者不需要關注對象的建立細節，對象的建立由相關的工廠來完成。就像我們去商場購買商品時，不需要知道商品是怎麼生産出來一樣，因為它們由專門的廠商生産。

建立型模式分為以下5種。

  單例（Singleton）模式：某個類隻能生成一個執行個體，該類提供了一個全局通路點供外部擷取該執行個體，其拓展是有限多例模式。

  原型（Prototype）模式：将一個對象作為原型，通過對其進行複制而克隆出多個和原型類似的新執行個體。

  工廠方法（FactoryMethod）模式：定義一個用于建立産品的接口，由子類決定生産什麼産品。

  抽象工廠（AbstractFactory）模式：提供一個建立産品族的接口，其每個子類可以生産一系列相關的産品。

  建造者（Builder）模式：将一個複雜對象分解成多個相對簡單的部分，然後根據不同需要分别建立它們，最後建構成該複雜對象。

結構型模式

  結構型模式：把類或對象結合在一起形成一個更大的結構。由于組合關系或聚合關系比繼承關系耦合度低，滿足“合成複用原則”，是以對象結構型模式比類結構型模式具有更大的靈活性。

  結構型模式分為以下 7 種：

  代理（Proxy）模式：為某對象提供一種代理以控制對該對象的通路。即用戶端通過代理間接地通路該對象，進而限制、增強或修改該對象的一些特性。

  擴充卡（Adapter）模式：将一個類的接口轉換成客戶希望的另外一個接口，使得原本由于接口不相容而不能一起工作的那些類能一起工作。

  橋接（Bridge）模式：将抽象與實作分離，使它們可以獨立變化。它是用組合關系代替繼承關系來實作的，進而降低了抽象和實作這兩個可變次元的耦合度。

  裝飾（Decorator）模式：動态地給對象增加一些職責，即增加其額外的功能。

  外觀（Facade）模式：為多個複雜的子系統提供一個一緻的接口，使這些子系統更加容易被通路。

  享元（Flyweight）模式：運用共享技術來有效地支援大量細粒度對象的複用。

  組合（Composite）模式：将對象組合成樹狀層次結構，使使用者對單個對象群組合對象具有一緻的通路性。

行為型模式

  行為型模式：用于描述程式在運作時複雜的流程控制，即描述多個類或對象之間怎樣互相協作共同完成單個對象都無法單獨完成的任務，它涉及算法與對象間職責的配置設定。行為型模式分為類行為模式和對象行為模式，前者采用繼承機制來在類間分派行為，後者采用組合或聚合在對象間配置設定行為。由于組合關系或聚合關系比繼承關系耦合度低，滿足“合成複用原則”，是以對象行為模式比類行為模式具有更大的靈活性。

行為型模式是設計模式中最為龐大的一類，它包含以下 11 種模式。

  模闆方法（Template Method）模式：定義一個操作中的算法骨架，将算法的一些步驟延遲到子類中，使得子類在可以不改變該算法結構的情況下重定義該算法的某些特定步驟。

  政策（Strategy）模式：定義了一系列算法，并将每個算法封裝起來，使它們可以互相替換，且算法的改變不會影響使用算法的客戶。

  指令（Command）模式：将一個請求封裝為一個對象，使送出請求的責任和執行請求的責任分割開。

  職責鍊（Chain of Responsibility）模式：把請求從鍊中的一個對象傳到下一個對象，直到請求被響應為止。通過這種方式去除對象之間的耦合。

  狀态（State）模式：允許一個對象在其内部狀态發生改變時改變其行為能力。

  觀察者（Observer）模式：多個對象間存在一對多關系，當一個對象發生改變時，把這種改變通知給其他多個對象，進而影響其他對象的行為。

  中介者（Mediator）模式：定義一個中介對象來簡化原有對象之間的互動關系，降低系統中對象間的耦合度，使原有對象之間不必互相了解。

  疊代器（Iterator）模式：提供一種方法來順序通路聚合對象中的一系列資料，而不暴露聚合對象的内部表示。

  通路者（Visitor）模式：在不改變集合元素的前提下，為一個集合中的每個元素提供多種通路方式，即每個元素有多個通路者對象通路。

  備忘錄（Memento）模式：在不破壞封裝性的前提下，擷取并儲存一個對象的内部狀态，以便以後恢複它。

  解釋器（Interpreter）模式：提供如何定義語言的文法，以及對語言句子的解釋方法，即解釋器。

  其實還有兩類：并發型模式和線程池模式

參考

1、Java之美[從菜鳥到高手演變] 之設計模式