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

設計模式(英語 design pattern)是對面向對象設計中反復出現(xiàn)的問題的解決方案。這個術語是在1990年代由Erich Gamma等人從建筑設計領域引入到計算機科學中來的。這個術語的含義還存有爭議。算法不是設計模式，因為算法致力于解決問題而非設計問題。設計模式通常描述了一組相互緊密作用的類與對象。設計模式提供一種討論軟件設計的公共語言，使得熟練設計者的設計經(jīng)驗可以被初學者和其他設計者掌握。設計模式還為軟件重構提供了目標。

隨著軟件開發(fā)社群對設計模式的興趣日益增長，已經(jīng)出版了一些相關的專著，定期召開相應的研討會，而且Ward Cunningham為此發(fā)明了WikiWiki用來交流設計模式的經(jīng)驗。

提示：本教程將通過?Java?實例，一步一步向您講解設計模式的概念。所以你需要對Java知識有所了解。

表述格式

表述一個軟件設計模式的格式根據(jù)作者的不同，劃分和名稱等都會有所不同。常用的GoF描述模式的格式大致分為以下這些部分：

• 模式名：每一個模式都有自己的名字，模式的名字使得我們可以討論我們的設計。

• 問題：在面向對象的系統(tǒng)設計過程中反復出現(xiàn)的特定場合，它導致我們采用某個模式。

• 解決方案：上述問題的解決方案，其內(nèi)容給出了設計的各個組成部分，它們之間的關系、職責劃分和協(xié)作方式。

• 別名：一個模式可以有超過一個以上的名稱。這些名稱應該要在這一節(jié)注明。

• 動機：在哪種情況使用該模式，是本節(jié)提供的方案（包括問題與來龍去脈）的責任。

• 適用性：模式適用于哪些情況、模式的背景等等。

• 結構：這部分常用類圖與交互圖闡述此模式。

• 參與者：這部分提供一份本模式用到的類與對象清單，與它們在設計下扮演的角色。

• 合作：描述在此模式下，類與對象間的交互。

• 影響：采用該模式對軟件系統(tǒng)其他部分的影響，比如對系統(tǒng)的擴充性、可移植性的影響。影響也包括負面的影響。這部分應描述使用本模式后的結果、副作用、與權衡(trade-off)

• 實現(xiàn)：這部分應描述實現(xiàn)該模式、該模式的部分方案、實現(xiàn)該模式的可能技術、或者建議實現(xiàn)模式的方法。

• 示例：簡略描繪出如何以編程語言來使用模式。

• 已知應用：業(yè)界已知的實現(xiàn)示例。

• 相關模式：這部分包括其他相關模式，以及與其他類似模式的不同。

提示：我們的《設計模式》教程將幫助您學習所有設計模式知識。如果你有任何疑問，請前往PHP中文網(wǎng)社區(qū)提出你的問題，會有熱心網(wǎng)友為你解答。

模式原則

大家都開始注意設計模式。那么，到底我們?yōu)槭裁匆迷O計模式呢？這么多設計模式為什么要怎么設計呢？

說實話，以前我還真沒搞清楚。就是看大家一口一個"Design pattern"，心就有點發(fā)虛。于是就買了本"四人幫"的設計模式，結果看得似懂非懂:看得時候好像是懂了，過一會就忘了。可能是本人比較"愚鈍"吧:))最近，有了點感悟。"獨樂不如眾樂"，與大家分享一下，還望指教!?

為什么要提倡"Design Pattern"呢？根本原因是為了代碼復用，增加可維護性。

那么怎么才能實現(xiàn)代碼復用呢？OO界有前輩的幾個原則："開－閉"原則(Open Closed Principal)、里氏代換原則、合成復用原則。設計模式就是實現(xiàn)了這些原則，從而達到了代碼復用、增加可維護性的目的。

• 開－閉原則

此原則是由"Bertrand Meyer"提出的。原文是："Software entities should be open for extension,but closed for modification"。就是說模塊應對擴展開放，而對修改關閉。模塊應盡量在不修改原(是"原"，指原來的代碼)代碼的情況下進行擴展。那么怎么擴展呢？我們看工廠模式"factory pattern":假設中關村有一個賣盜版盤和毛片的小子，我們給他設計一"光盤銷售管理軟件"。我們應該先設計一"光盤"接口。如圖：【pre】______________|<>|| 光盤 ||_____________|| 賣() || ||_____________|【/pre】而盜版盤和毛片是其子類。小子通過"DiscFactory"來管理這些光盤。代碼為：

publicclassDiscFactory{
publicstatic光盤
getDisc(Stringname){
return(光盤)Class.forName(name).getInstance();
}
}

有人要買盜版盤，怎么實現(xiàn)呢？

public class 小子{ public static void main(String【】 args){ 光盤 d=DiscFactory.getDisc("盜版盤"); 光盤.賣(); } }

如果有一天，這小子良心發(fā)現(xiàn)了，開始賣正版軟件。沒關系，我們只要再創(chuàng)建一個"光盤"的子類"正版軟件"就可以了。不需要修改原結構和代碼。怎么樣？對擴展開放，對修改關閉。"開-閉原則" 工廠模式是對具體產(chǎn)品進行擴展，有的項目可能需要更多的擴展性，要對這個"工廠"也進行擴展，那就成了"抽象工廠模式"。

• 里氏代換原則

里氏代換原則是由"Barbara Liskov"提出的。如果調(diào)用的是父類的話，那么換成子類也完全可以運行。比如： 光盤 d=new 盜版盤(); d.賣(); 要將"盜版盤"類改為"毛片"類，沒問題，完全可以運行。Java編譯程序會檢查程序是否符合里氏代換原則。還記得java繼承的一個原則嗎？子類override方法的訪問權限不能小于父類對應方法的訪問權限。比如"光盤"中的方法"賣"訪問權限是"public"，那么"盜版盤"和"毛片"中的"賣"方法就不能是protected或private，編譯不能通過。為什么要這樣呢？你想?。喝绻?盜版盤"的"賣"方法是private。那么下面這段代碼就不能執(zhí)行了： 光盤 d=new 盜版盤(); d.賣();可以說：里氏代換原則是繼承復用的一個基礎。

• 合成復用原則

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

在Java中，應盡量針對Interface編程，而非實現(xiàn)類。這樣，更換子類不會影響調(diào)用它方法的代碼。要讓各個類盡可能少的跟別人聯(lián)系，"不要與陌生人說話"。這樣，城門失火，才不至于殃及池魚。擴展性和維護性才能提高

理解了這些原則，再看設計模式，只是在具體問題上怎么實現(xiàn)這些原則而已。張無忌學太極拳，忘記了所有招式，打倒了"玄冪二老"，所謂"心中無招"。設計模式可謂招數(shù)，如果先學通了各種模式，又忘掉了所有模式而隨心所欲，可謂OO之最高境界。呵呵，搞笑，搞笑?。↗R）

依賴倒轉原則抽象不應該依賴與細節(jié)，細節(jié)應當依

• 依賴倒轉原則

要針對接口編程，而不是針對實現(xiàn)編程。傳遞參數(shù)，或者在組合聚合關系中，盡量引用層次高的類。主要是在構造對象時可以動態(tài)的創(chuàng)建各種具體對象，當然如果一些具體類比較穩(wěn)定，就不必在弄一個抽象類做它的父類，這樣有畫舌添足的感覺接口隔離原則定制服務的例子，每一

• 接口隔離原則

一種角色，不多不少，不干不該干的事，該干的事都要干 抽象類抽象類不會有實例

• 抽象類

類為子類繼承，一般包含這個系的共同屬性和方法。注意：好的繼承關系中，只有葉節(jié)點是具體類，其他節(jié)點應該都是抽象類，也就是說具體類是不被繼承的。將盡可能多的共同代碼放到抽象類中。 7 迪米特法則最少知識原則。不要和陌生人說話。

本設計模式教程手冊涵蓋的內(nèi)容

本設計模式教程涵蓋所有設計模式介紹，包含了工廠模式（Factory Pattern）、抽象工廠模式（Abstract Factory Pattern）、單例模式（Singleton Pattern）、建造者模式（Builder Pattern）、原型模式（Prototype Pattern）等等。

提示：本教程的每一章都包含了很多Java實例，通過這些例子將幫助您更好地學習理解設計模式。