設計模式入門-設計模式的原則

設計模式的原則
1、"開－閉"原則——模組應對擴充開放，而對修改關閉。
2、裡氏代換原則——如果調用的是父類的話，那麼換成子類也完全可以運行。裡氏代換原則是繼承複用的一個基礎。
3、合成複用原則——要少用繼承，多用合成關係來實現。
4、依賴倒轉原則——抽象不應該依賴與細節，細節應當依賴與抽象。
                   要針對介面編程，而不是針對實現編程。
5、介面隔離原則——每一個介面應該是一種角色，不多不少，不幹不該乾的事，該乾的事都要幹。
6、抽象類別
7、迪米特法則——最少知識原則。不要和陌生人說話。 

    設計模式（Design pattern）是一套被反覆使用、多數人知曉的、經過分類編目的、代碼設計經驗的總結。使用設計模式是為了可重用代碼、讓代碼更容易被他人理解、保證代碼可靠性。

    毫無疑問，設計模式於己於他人於系統都是多贏的，設計模式使代碼編製真正工程化，設計模式是軟體工程的基石，如同大廈的一塊塊磚石一樣。

    GoF的“設計模式”是第一次將設計模式提升到理論高度，並將之正常化，本書提出了23種基本設計模式，自此，在可複用物件導向軟體的發展過程中，新的大量的設計模式不斷出現。

一、設計模式和架構

    現在，可複用物件導向軟體系統現在一般劃分為三大類：應用程式工具箱和架構(Framework),我們平時開發的具體軟體都是應用程式；Java的API屬於工具箱;而架構是構成一類特定軟體可複用設計的一組相互協作的類。EJB（EnterpriseJavaBeans）是Java應用於企業計算的架構.

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

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

二、設計模式的原則

   近年來，大家都開始注意設計模式。那麼，到底我們為什麼要用設計模式呢？這麼多設計模式為什麼要這麼設計呢？說實話，以前我還真沒搞清楚。就是看大家一口一個"Design pattern"，心就有點發虛。於是就買了本"四人幫"的設計模式，結果看得似懂非懂:看得時候好像是懂了，過一會就忘了。可能是本人比較"愚鈍"吧:))最近，有了點感悟。"獨樂不如眾樂"，與大家分享一下，還望指教!
    為什麼要提倡"Design Pattern"呢？根本原因是為了代碼複用，增加可維護性。那麼怎麼才能實現代碼複用呢？OO界有前輩的幾個原則："開－閉"原則(Open Closed Principal)、裡氏代換原則、合成複用原則。設計模式就是實現了這些原則，從而達到了代碼複用、增加可維護性的目的。

    1、"開－閉"原則

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

public class DiscFactory{
    public static 光碟片 getDisc(java/lang/String.java.html" target="_blank">String name){
       return (光碟片)java/lang/Class.java.html" target="_blank">Class.forName(name).getInstance();
    }
}
有人要買盜版盤，怎麼實現呢？

public class 小子{
    public static void main(java/lang/String.java.html" target="_blank">String[] args){
        光碟片 d=DiscFactory.getDisc("盜版盤");
        光碟片.賣();
    }
}

    如果有一天，這小子良心發現了，開始賣正版軟體。沒關係，我們只要再建立一個"光碟片"的子類"正版軟體"就可以了。不需要修改原結構和代碼。怎麼樣？對擴充開發，對修改關閉。"開-閉原則"
    原廠模式是對具體產品進行擴充，有的項目可能需要更多的擴充性，要對這個"工廠"也進行擴充，那就成了"抽象原廠模式"。

    2、裡氏代換原則

裡氏代換原則是由"Barbara Liskov"提出的。如果調用的是父類的話，那麼換成子類也完全可以運行。比如：
       光碟片 d=new 盜版盤();
       d.賣();
    現在要將"盜版盤"類改為"毛片"類，沒問題，完全可以運行。Java編譯器會檢查程式是否符合裡氏代換原則。還記得java繼承的一個原則嗎？子類 overload方法的存取權限不能小於父類對應方法的存取權限。比如"光碟片"中的方法"賣"存取權限是"public"，那麼"盜版盤"和"毛片"中的"賣"方法就不能是package或private，編譯不能通過。為什麼要這樣呢？你想啊：如果"盜版盤"的"賣"方法是private。那麼下面這段代碼就不能執行了：
            光碟片 d=new 盜版盤();
            d.賣();
可以說：裡氏代換原則是繼承複用的一個基礎。

    3、合成複用原則

    就是說要少用繼承，多用合成關係來實現。我曾經這樣寫過程式：有幾個類要與資料庫打交道，就寫了一個資料庫操作的類，然後別的跟資料庫打交道的類都繼承這個。結果後來，我修改了資料庫操作類的一個方法，各個類都需要改動。"牽一髮而動全身"!物件導向是要把波動限制在盡量小的範圍。

    在Java中，應盡量針對Interface編程，而非實作類別。這樣，更換子類不會影響調用它方法的代碼。要讓各個類儘可能少的跟別人聯絡，"不要與陌生人說話"。這樣，城門失火，才不至於殃及池魚。擴充性和維護性才能提高

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

      4 依賴倒轉原則

抽象不應該依賴與細節，細節應當依賴與抽象。

要針對介面編程，而不是針對實現編程。

傳遞參數，或者在組合彙總關係中，盡量引用層次高的類。

主要是在構造對象時可以動態建立各種具體對象，當然如果一些具體類比較穩定，就不必在弄一個抽象類別做它的父類，這樣有畫舌添足的感覺

      5 介面隔離原則

定製服務的例子，每一個介面應該是一種角色，不多不少，不幹不該乾的事，該乾的事都要幹

      6 抽象類別

抽象類別不會有執行個體，一般作為父類為子類繼承，一般包含這個系的共同屬性和方法。

注意：好的繼承關係中，只有分葉節點是具體類，其他節點應該都是抽象類別，也就是說具體類

是不被繼承的。將儘可能多的共同代碼放到抽象類別中。

      7 迪米特法則

最少知識原則。不要和陌生人說話。

本文來自CSDN部落格，轉載請標明出處：http://blog.csdn.net/Cnami/archive/2008/07/18/2675147.aspx