軟件設計模式: 基本概念匯總

設計模式（Design pattern）是一套被反復使用、多數人知曉的、經過分類編目的、代碼設計經驗的總結。使用設計模式是為了可重用代碼、讓代碼更容易被他人理解、保證代碼可靠性。 毫無疑問，設計模式於己於他人於系統都是多贏的；設計模式使代碼編制真正工程化；設計模式是軟件工程的基石脈絡，如同大廈的結構一樣。

設計框架 

可復用面向對象軟件系統一般划分為兩大類： 應用程序工具箱和 框架（Framework），我們平時開發的具體軟件都是應用程序，Java的API屬於工具箱；而框架是構成一類特定軟件可復用設計的一組相互協作的類，EJB（EnterpriseJavaBeans）是 Java應用於 企業計算的 框架。

框架通常定義了應用體系的整體結構類和對象的關系等等設計參數，以便於具體應用實現者能集中精力於應用本身的特定細節。框架主要記錄軟件應用中共同的設計決策，框架強調設計復用，因此框架設計中必然要使用設計模式。

另外，設計模式有助於對框架結構的理解，成熟的框架通常使用了多種設計模式,如果你熟悉這些設計模式，毫無疑問，你將迅速掌握框架的結構，我們一般開發者如果突然接觸EJB、Spring等框架，會覺得特別難學、難掌握，那么轉而先掌握設計模式，無疑是給了你剖析EJB或 J2EE系統的一把利器。

設計原則

為什么要提倡“Design Pattern呢？根本原因是為了代碼復用，增加可維護性。那么怎么才能實現代碼復用呢？面向對象有幾個原則： 開閉原則（Open Closed Principle，OCP）、 里氏代換原則（Liskov Substitution Principle，LSP）、 依賴倒轉原則（Dependency Inversion Principle，DIP）、 接口隔離原則（Interface Segregation Principle，ISP）、合成/聚合復用原則（Composite/Aggregate Reuse Principle，CARP）、最小知識原則（Principle of Least Knowledge，PLK，也叫迪米特法則）。開閉原則具有理想主義的色彩，它是面向對象設計的終極目標。其他幾條，則可以看做是開閉原則的實現方法。

設計模式就是實現了這些原則，從而達到了代碼復用、增加可維護性的目的。

1. 開閉原則
此原則是由Bertrand Meyer提出的。原文是：“Software entities should be open for extension,but closed for modification”。就是說模塊應對擴展開放，而對修改關閉。模塊應盡量在不修改原（是“原”，指原來的代碼）代碼的情況下進行擴展。
2. 里氏代換原則
里氏代換原則是由Barbara Liskov提出的。如果調用的是父類的話，那么換成子類也完全可以運行。
可以說：里氏代換原則是繼承復用的一個基礎。
3. 依賴倒轉原則
抽象不應該依賴於細節，細節應當依賴於抽象。
要針對接口編程，而不是針對實現編程。
傳遞參數，或者在組合聚合關系中，盡量引用層次高的類。
主要是在構造對象時可以動態的創建各種具體對象，當然如果一些具體類比較穩定，就不必在弄一個 抽象類做它的父類，這樣有畫蛇添足的感覺
4. 合成/聚合復用原則

合成/聚合復用原則（Composite/Aggregate Reuse Principle，CARP）經常又叫做合成復用原則。合成/聚合復用原則就是在一個新的對象里面使用一些已有的對象，使之成為新對象的一部分；新的對象通過向這些對象的委派達到復用已有功能的目的。它的設計原則是：要盡量使用合成/聚合，盡量不要使用繼承。

就是說要少用繼承，多用合成關系來實現。我曾經這樣寫過程序：有幾個類要與數據庫打交道，就寫了一個數據庫操作的類，然后別的跟數據庫打交道的類都繼承這個。結果后來，我修改了數據庫操作類的一個方法，各個類都需要改動。“牽一發而動全身”！面向對象是要把波動限制在盡量小的范圍。

5. 接口隔離原則
定制服務的例子，每一個接口應該是一種角色，不多不少，不干不該干的事，該干的事都要干。
最少知識原則
也叫迪米特法則。不要和陌生人說話，即一個對象應對其他對象有盡可能少的了解。

 

設計模式分為三種類型，共23種。
創建型模式：單例模式、抽象工廠模式、建造者模式、工廠模式、原型模式。
結構型模式：適配器模式、橋接模式、裝飾模式、組合模式、外觀模式、享元模式、代理模式。

行為型模式：模版方法模式、命令模式、迭代器模式、觀察者模式、中介者模式、備忘錄模式、解釋器模式、狀態模式、策略模式、職責鏈模式、訪問者模式。

 

Abstract Factory（ 抽象工廠模式）：提供一個創建一系列相關或相互依賴對象的接口，而無需指定它們具體的類。

Adapter（ 適配器模式）：將一個類的接口轉換成客戶希望的另外一個接口。Adapter模式使得原本由於接口不兼容而不能一起工作的那些類可以一起工作。

Bridge（ 橋接模式）：將抽象部分與它的實現部分分離，使它們都可以獨立地變化。

Builder（ 建造者模式）：將一個復雜對象的構建與它的表示分離，使得同樣的構建過程可以創建不同的表示。

Chain of Responsibility（職責鏈模式）：為解除請求的發送者和接收者之間耦合，而使多個對象都有機會處理這個請求。將這些對象連成一條鏈，並沿着這條鏈傳遞該請求，直到有一個對象處理它。

Command（ 命令模式）：將一個請求封裝為一個對象，從而使你可用不同的請求對客戶進行參數化；對請求排隊或記錄請求日志，以及支持可取消的操作。

Composite（ 組合模式）：將對象組合成樹形結構以表示“部分-整體”的層次結構。它使得客戶對單個對象和復合對象的使用具有一致性。

Decorator（ 裝飾模式）：動態地給一個對象添加一些額外的職責。就擴展功能而言， 它比生成子類方式更為靈活。

Facade（ 外觀模式）：為子系統中的一組接口提供一個一致的界面，Facade模式定義了一個高層接口，這個接口使得這一子系統更加容易使用。

Factory Method（ 工廠模式）：定義一個用於創建對象的接口，讓子類決定將哪一個類實例化。Factory Method使一個類的實例化延遲到其子類。

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

Interpreter（解析器模式）：給定一個語言, 定義它的文法的一種表示，並定義一個解釋器, 該解釋器使用該表示來解釋語言中的句子。

Iterator（ 迭代器模式）：提供一種方法順序訪問一個聚合對象中各個元素，而又不需暴露該對象的內部表示。

Mediator（ 中介模式）：用一個中介對象來封裝一系列的對象交互。中介者使各對象不需要顯式地相互引用，從而使其耦合松散，而且可以獨立地改變它們之間的交互。

Memento（ 備忘錄模式）：在不破壞封裝性的前提下，捕獲一個對象的內部狀態，並在該對象之外保存這個狀態。這樣以后就可將該對象恢復到保存的狀態。

Observer（ 觀察者模式）：定義對象間的一種一對多的依賴關系,以便當一個對象的狀態發生改變時,所有依賴於它的對象都得到通知並自動刷新。

Prototype（ 原型模式）：用原型實例指定創建對象的種類，並且通過拷貝這個原型來創建新的對象。

Proxy（ 代理模式）：為其他對象提供一個代理以控制對這個對象的訪問。

Singleton（ 單例模式）：保證一個類僅有一個實例，並提供一個訪問它的全局訪問點。 單例模式是最簡單的設計模式之一，但是對於Java的開發者來說，它卻有很多缺陷。在九月的專欄中，David Geary探討了單例模式以及在面對多線程（multi-threading）、類裝載器（class loaders）和序列化（serialization）時如何處理這些缺陷。

State（ 狀態模式）：允許一個對象在其內部狀態改變時改變它的行為。對象看起來似乎修改了它所屬的類。

Strategy（ 策略模式）：定義一系列的算法,把它們一個個封裝起來, 並且使它們可相互替換。本模式使得算法的變化可獨立於使用它的客戶。

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

Visitor（ 訪問者模式）：表示一個作用於某對象結構中的各元素的操作。它使你可以在不改變各元素的類的前提下定義作用於這些元素的新操作。