0.設(shè)計模式的分類

GoF提出的設(shè)計模式總共有23種，根據(jù)目的準則分類分為三大類：

創(chuàng)建型模式，共五種：單例模式、工廠方法模式、抽象工廠模式、建造者模式、原型模式。
結(jié)構(gòu)型模式，共七種：適配器模式、裝飾模式、代理模式、外觀模式、橋接模式、組合模式、享元模式。
行為型模式，共十一種：策略模式、模板方法模式、觀察者模式、迭代器模式、責(zé)任鏈模式、命令模式、備忘錄模式、狀態(tài)模式、訪問者模式、中介者模式、解釋器模式。
另外隨著設(shè)計模式的發(fā)展也涌現(xiàn)出很多新的設(shè)計模式：它們分別是規(guī)格模式、對象池模式、雇工模式、黑板模式和空對象模式等。

1. 單一職責(zé)原則(SRP)

定義：就一個類而言，應(yīng)該僅有一個引起它變化的原因。
從這句定義我們很難理解它的含義，通俗講就是我們不要讓一個類承擔(dān)過多的職責(zé)。如果一個類承擔(dān)的職責(zé)過多，就等于把這些職責(zé)耦合在一起，一個職責(zé)的變化可能會削弱或者抑制這個類完成其他職責(zé)的能力。這種耦合會導(dǎo)致脆弱的設(shè)計，當變化發(fā)生時，設(shè)計會遭受到破壞。
比如我經(jīng)?？吹揭恍〢ndroid開發(fā)在Activity中寫B(tài)ean文件，網(wǎng)絡(luò)數(shù)據(jù)處理，如果有列表的話Adapter 也寫在Activity中，問他們?yōu)槭裁闯撕谜乙矝]啥理由了，把他們拆分到其他類豈不是更好找，如果Activity過于臃腫行數(shù)過多，顯然不是好事，如果我們要修改Bean文件，網(wǎng)絡(luò)處理和Adapter都需要上這個Activity來修改，就會導(dǎo)致引起這個Activity變化的原因太多，我們在版本維護時也會比較頭疼。也就嚴重違背了定義“就一個類而言，應(yīng)該僅有一個引起它變化的原因”。
當然如果想爭論的話，這個模式是可以引起很多爭論的，但請記住一點，你寫代碼不只是為了你也是為了其他人。

2. 開放封閉原則(ASD)

定義：類、模塊、函數(shù)等等等應(yīng)該是可以拓展的，但是不可修改。
開放封閉有兩個含義，一個是對于拓展是開放的，另一個是對于修改是封閉的。對于開發(fā)來說需求肯定是要變化的，但是新需求一來，我們就要把類重新改一遍這顯然是令人頭疼的，所以我們設(shè)計程序時面對需求的改變要盡可能的保證相對的穩(wěn)定，盡量用新代碼實現(xiàn)拓展來修改需求，而不是通過修改原有的代碼來實現(xiàn)。
假設(shè)我們要實現(xiàn)一個列表，一開始只有查詢的功能，如果產(chǎn)品又要增加添加功能，過幾天又要增加刪除功能，大多數(shù)人的做法是寫個方法然后通過傳入不同的值來控制方法來實現(xiàn)不同的功能，但是如果又要新增功能我們還得修改我們的方法。用開發(fā)封閉原則解決就是增加一個抽象的功能類，讓增加和刪除和查詢的作為這個抽象功能類的子類，這樣如果我們再添加功能，你會發(fā)現(xiàn)我們不需要修改原有的類，只需要添加一個功能類的子類實現(xiàn)功能類的方法就可以了。

3.里氏替換原則(LSP)

定義：所有引用基類（父類）的地方必須能透明地使用其子類的對象
里氏代換原則告訴我們，在軟件中將一個基類對象替換成它的子類對象，程序?qū)⒉粫a(chǎn)生任何錯誤和異常，反過來則不成立，如果一個軟件實體使用的是一個子類對象的話，那么它不一定能夠使用基類對象。
里氏代換原則是實現(xiàn)開閉原則的重要方式之一，由于使用基類對象的地方都可以使用子類對象，因此在程序中盡量使用基類類型來對對象進行定義，而在運行時再確定其子類類型，用子類對象來替換父類對象。
在使用里氏代換原則時需要注意如下幾個問題：

子類的所有方法必須在父類中聲明，或子類必須實現(xiàn)父類中聲明的所有方法。根據(jù)里氏代換原則，為了保證系統(tǒng)的擴展性，在程序中通常使用父類來進行定義，如果一個方法只存在子類中，在父類中不提供相應(yīng)的聲明，則無法在以父類定義的對象中使用該方法。
我們在運用里氏代換原則時，盡量把父類設(shè)計為抽象類或者接口，讓子類繼承父類或?qū)崿F(xiàn)父接口，并實現(xiàn)在父類中聲明的方法，運行時，子類實例替換父類實例，我們可以很方便地擴展系統(tǒng)的功能，同時無須修改原有子類的代碼，增加新的功能可以通過增加一個新的子類來實現(xiàn)。里氏代換原則是開閉原則的具體實現(xiàn)手段之一。
Java語言中，在編譯階段，Java編譯器會檢查一個程序是否符合里氏代換原則，這是一個與實現(xiàn)無關(guān)的、純語法意義上的檢查，但Java編譯器的檢查是有局限的。

4.依賴倒置原則(DIP)

定義：高層模塊不應(yīng)該依賴低層模塊，兩個都應(yīng)該依賴于抽象。抽象不應(yīng)該依賴于細節(jié)，細節(jié)應(yīng)該依賴于抽象。
在Java中，抽象就是指接口或者抽象類，兩者都是不能直接被實例化的；細節(jié)就是實現(xiàn)類，實現(xiàn)接口或者繼承抽象類而產(chǎn)生的就是細節(jié)，也就是可以加上一個關(guān)鍵字new產(chǎn)生的對象。高層模塊就是調(diào)用端，低層模塊就是具體實現(xiàn)類。
依賴倒置原則在Java中的表現(xiàn)就是：模塊間通過抽象發(fā)生，實現(xiàn)類之間不發(fā)生直接依賴關(guān)系，其依賴關(guān)系是通過接口或者抽象類產(chǎn)生的。如果類與類直接依賴細節(jié)，那么就會直接耦合，那么當修改時，就會同時修改依賴者代碼，這樣限制了可擴展性。

5.迪米特原則(LOD)

定義：一個軟件實體應(yīng)當盡可能少地與其他實體發(fā)生相互作用。
也稱為最少知識原則。如果一個系統(tǒng)符合迪米特法則，那么當其中某一個模塊發(fā)生修改時，就會盡量少地影響其他模塊，擴展會相對容易，這是對軟件實體之間通信的限制，迪米特法則要求限制軟件實體之間通信的寬度和深度。迪米特法則可降低系統(tǒng)的耦合度，使類與類之間保持松散的耦合關(guān)系。
迪米特法則要求我們在設(shè)計系統(tǒng)時，應(yīng)該盡量減少對象之間的交互，如果兩個對象之間不必彼此直接通信，那么這兩個對象就不應(yīng)當發(fā)生任何直接的相互作用，如果其中的一個對象需要調(diào)用另一個對象的某一個方法的話，可以通過第三者轉(zhuǎn)發(fā)這個調(diào)用。簡言之，就是通過引入一個合理的第三者來降低現(xiàn)有對象之間的耦合度。
在將迪米特法則運用到系統(tǒng)設(shè)計中時，要注意下面的幾點：在類的劃分上，應(yīng)當盡量創(chuàng)建松耦合的類，類之間的耦合度越低，就越有利于復(fù)用，一個處在松耦合中的類一旦被修改，不會對關(guān)聯(lián)的類造成太大波及；在類的結(jié)構(gòu)設(shè)計上，每一個類都應(yīng)當盡量降低其成員變量和成員函數(shù)的訪問權(quán)限；在類的設(shè)計上，只要有可能，一個類型應(yīng)當設(shè)計成不變類；在對其他類的引用上，一個對象對其他對象的引用應(yīng)當降到最低。

6.接口隔離原則(ISP)

定義：一個類對另一個類的依賴應(yīng)該建立在最小的接口上。
建立單一接口，不要建立龐大臃腫的接口，盡量細化接口，接口中的方法盡量少。也就是說，我們要為各個類建立專用的接口，而不要試圖去建立一個很龐大的接口供所有依賴它的類去調(diào)用。
采用接口隔離原則對接口進行約束時，要注意以下幾點：

接口盡量小，但是要有限度。對接口進行細化可以提高程序設(shè)計靈活性，但是如果過小，則會造成接口數(shù)量過多，使設(shè)計復(fù)雜化。所以一定要適度。
為依賴接口的類定制服務(wù)，只暴露給調(diào)用的類它需要的方法，它不需要的方法則隱藏起來。只有專注地為一個模塊提供定制服務(wù)，才能建立最小的依賴關(guān)系。
提高內(nèi)聚，減少對外交互。使接口用最少的方法去完成最多的事情。
這六個原則，可以使我們在應(yīng)用的迭代維護中更加方便、輕松的應(yīng)對，讓我們的軟件更加靈活。在后續(xù)的文章中我會給大家介紹其他的設(shè)計模式。