設計模式——概述

設計模式——概述

設計模式（Design pattern）是一套被反覆使用、多數人知曉的、通過分類編目的、代碼設計經驗的總結。使用設計模式是爲了可重用代碼、讓代碼更容易被他人理解、保證代碼可靠性。毫無疑問，設計模式於己於他人於系統都是多贏的，設計模式使代碼編制真正工程化，能夠稱得上是軟件工程的基石。

GoF的「設計模式」是第一次將設計模式提高到理論高度，並將之規範化，本書提出了23種基本設計模式，自此，在可複用面向對象軟件的發展過程當中，新的大量的設計模式不斷出現。

項目中合理的運用設計模式能夠完美的解決不少問題，每種模式如今都有相應的原理來與之對應，每個模式描述了一個在咱們周圍不斷重複發生的問題，以及該問題的核心解決方案，這也是它能被普遍應用的緣由。

1、設計模式和框架

如今，可複用面向對象軟件系統如今通常劃分爲三大類：應用程序工具箱和框架(Framework)，咱們平時開發的具體軟件都是應用程序；Java的API屬於工具箱；而框架是構成一類特定軟件可複用設計的一組相互協做的類。

框架一般定義了應用體系的總體結構類和對象的關係等等設計參數，以便於具體應用實現者能集中精力於應用自己的特定細節。框架主要記錄軟件應用中共同的設計決策，框架強調設計複用，所以框架設計中必然要使用設計模式.

另外，設計模式有助於對框架結構的理解，成熟的框架一般使用了多種設計模式，若是你熟悉這些設計模式，毫無疑問，你將迅速掌握框架的結構，咱們通常開發者若是忽然接觸EJB等框架，會以爲特別難學，難掌握，那麼轉而先掌握設計模式，無疑是給了你剖析EJB的一把利器。

2、設計模式的原則

近年來，你們都開始注意設計模式。那麼，到底咱們爲何要用設計模式呢？這麼多設計模式爲何要這麼設計呢？根本緣由是爲了代碼複用，增長可維護性。那麼怎麼才能實現代碼複用呢？OO界有前輩的幾個原則：「開－閉」原則(Open Closed Principal)、里氏代換原則、合成複用原則。設計模式就是實現了這些原則，從而達到了代碼複用、增長可維護性的目的。

1、「開－閉」原則

此原則是由「Bertrand Meyer」提出的。原文是：「Software entities should be open for extension,but closed for modification」。就是說模塊應對擴展開放，而對修改關閉。模塊應儘可能在不修改原(是「原」，指原來的代碼)代碼的狀況下進行擴展。那麼怎麼擴展呢？咱們看工廠模式「factory pattern」：假設中關村有一個賣盜版盤的小子，咱們給他設計一「光盤銷售管理軟件」。咱們應該先設計一「光盤」接口。而盜版軟件和盜版電影是其子類。小子經過「DiscFactory」來管理這些光盤。代碼爲：

public class DiscFactory{

public static 光盤 getDisc(String name){

return (光盤)Class.forName(name).getInstance();

}

}

有人要買盜版軟件，怎麼實現呢？

public class 小子{

public static void main(String[] args){

光盤 d=DiscFactory.getDisc("盜版軟件");

光盤.賣();

}

}

若是有一天，這小子良心發現了，開始賣正版軟件。不要緊，咱們只要再建立一個「光盤」的子類「正版軟件」就能夠了。不須要修改原結構和代碼。怎麼樣？對擴展開發，對修改關閉，「開-閉原則」。

工廠模式是對具體產品進行擴展，有的項目可能須要更多的擴展性，要對這個「工廠」也進行擴展，那就成了「抽象工廠模式」。

2、里氏代換原則

里氏代換原則是由「Barbara Liskov」提出的。若是調用的是父類的話，那麼換成子類也徹底能夠運行。好比：

光盤 d=new 盜版盤();

d.賣();

如今要將「盜版軟件」類改成「盜版電影」類，沒問題，徹底能夠運行。Java編譯程序會檢查程序是否符合里氏代換原則。還記得java繼承的一個原則嗎？子類 overload方法的訪問權限不能小於父類對應方法的訪問權限。好比「光盤」中的方法「賣」訪問權限是「public」，那麼「盜版軟件」和「盜版電影」中的「賣」方法就不能是package或private，編譯不能經過。爲何要這樣呢？若是「盜版軟件」的「賣」方法是private。那麼下面這段代碼就不能執行了：

光盤 d=new 盜版軟件();

d.賣();

能夠說：里氏代換原則是繼承複用的一個基礎。

3、合成複用原則

就是說要少用繼承，多用合成關係來實現。咱們可能曾經這樣寫過程序：有幾個類要與數據庫打交道，就寫了一個數據庫操做的類，而後別的跟數據庫打交道的類都繼承這個。結果後來，我修改了數據庫操做類的一個方法，各個類都須要改動。「牽一髮而動全身」！面向對象是要把波動限制在儘可能小的範圍。

在Java中，應儘可能針對Interface編程，而非實現類。這樣，更換子類不會影響調用它方法的代碼。要讓各個類儘量少的跟別人聯繫，擴展性和維護性才能提升。

4、依賴倒轉原則

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

要針對接口編程，而不是針對實現編程。

傳遞參數，或者在組合聚合關係中，儘可能引用層次高的類。

主要是在構造對象時能夠動態的建立各類具體對象，固然若是一些具體類比較穩定，就沒必要再弄一個抽象類作它的父類，這樣有多此一舉的感受

5、接口隔離原則

定製服務的例子，每個接口應該是一種角色，很少很多，不幹不應乾的事，該乾的事都要幹。下降依賴，下降耦合。

6、抽象類

抽象類不會有實例，通常做爲父類爲子類繼承，通常包含這個系的共同屬性和方法。

注意：好的繼承關係中，只有葉節點是具體類，其餘節點應該都是抽象類，也就是說具體類是不被繼承的。將盡量多的共同代碼放到抽象類中。

7、迪米特法則

最少知識原則。就是說：一個實體應當儘可能少的與其餘實體之間發生相互做用，使得系統功能模塊相對獨立。

3、設計模式的分類

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

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

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

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

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

上述各類設計模式將在接下來的一系列文章中爲你們一一呈現，敬請關注。