其他同系列的文章還有：
面向?qū)ο缶幊讨械牧笤瓌t
設(shè)計模式| 創(chuàng)建型模式
設(shè)計模式| 結(jié)構(gòu)型模式
設(shè)計模式| 行為型模式 (上)
設(shè)計模式| 行為型模式 (下)
歡迎閱讀，評論?。?！

前言

從面向過程到面向?qū)ο笫擒浖O(shè)計誕生以來的邁出的最偉大的一步，
使用面向?qū)ο笤O(shè)計，可以設(shè)計出優(yōu)秀的軟件，同樣也可以設(shè)計出糟糕的軟件。
只有遵循一些特定的原則，才能設(shè)計出復(fù)用性高靈活性好的軟件來。

在運(yùn)用面向?qū)ο蟮乃枷脒M(jìn)行軟件設(shè)計時，需要遵循的原則一共有6個，他們是：

1. 單一職責(zé)原則（Single Responsibility Principle）
2. 里氏替換原則（Liskov Substitution Principle）
3. 依賴倒置原則（Dependence Inversion Principle）
4. 接口隔離原則（Interface Segregation Principle）
5. 迪米特法則（Law Of Demeter）
6. 開閉原則（Open Close Principle）

在軟件設(shè)計的過程中，只要我們盡量遵循以上六條設(shè)計原則，
設(shè)計出來的軟件一定會是一個優(yōu)秀的軟件，它必定足夠健壯、足夠穩(wěn)定，并以極大的靈活性來迎接隨時而來的需求變更等因素。
當(dāng)完全明白這六個原則的含義時，小菜便完成了走向大牛的蛻變。

1、單一職責(zé)原則

即一個類只負(fù)責(zé)一項(xiàng)職責(zé)。

問題由來：

類T負(fù)責(zé)兩個不同的職責(zé)：職責(zé)P1，職責(zé)P2。當(dāng)由于職責(zé)P1需求發(fā)生改變而需要修改類T時，
有可能會導(dǎo)致原本運(yùn)行正常的職責(zé)P2功能發(fā)生故障。

解決方案：

遵循單一職責(zé)原則。分別建立兩個類T1、T2，使T1完成職責(zé)P1功能，T2完成職責(zé)P2功能。
這樣，當(dāng)修改類T1時，不會使職責(zé)P2發(fā)生故障風(fēng)險；同理，當(dāng)修改T2時，也不會使職責(zé)P1發(fā)生故障風(fēng)險。

說到單一職責(zé)原則，很多人都會不屑一顧。因?yàn)樗唵瘟?。稍有?jīng)驗(yàn)的程序員即使從來沒有讀過設(shè)計模式、從來沒有聽說過單一職責(zé)原則
在設(shè)計軟件時也會自覺的遵守這一重要原則，因?yàn)檫@是常識。在軟件編程中，誰也不希望因?yàn)樾薷牧艘粋€功能導(dǎo)致其他的功能發(fā)生故障。
而避免出現(xiàn)這一問題的方法便是遵循單一職責(zé)原則。

雖然單一職責(zé)原則如此簡單，并且被認(rèn)為是常識，但是即便是經(jīng)驗(yàn)豐富的程序員寫出的程序，也會有違背這一原則的代碼存在。
為什么會出現(xiàn)這種現(xiàn)象呢？

因?yàn)橛?strong>職責(zé)擴(kuò)散。所謂職責(zé)擴(kuò)散，就是因?yàn)槟撤N原因，職責(zé)P被分化為粒度更細(xì)的職責(zé)P1和P2。這是實(shí)際情況中非常容易出現(xiàn)的現(xiàn)象。

有一種方式?jīng)]有改動原來的方法，而是在類中新加了一個方法，這樣雖然也違背了單一職責(zé)原則，但在方法級別上卻是符合單一職責(zé)原則的，因?yàn)樗]有動原來方法的代碼。

我的原則是：只有邏輯足夠簡單，才可以在代碼級別上違反單一職責(zé)原則；只有類中方法數(shù)量足夠少，才可以在方法級別上違反單一職責(zé)原則；否則立即重構(gòu)出新的類。

遵循（類、方法）單一職責(zé)原的優(yōu)點(diǎn)有：

- 可以降低類的復(fù)雜度，一個類只負(fù)責(zé)一項(xiàng)職責(zé)，其邏輯肯定要比負(fù)責(zé)多項(xiàng)職責(zé)簡單的多；
- 提高類的可讀性，提高系統(tǒng)的可維護(hù)性；
- 變更引起的風(fēng)險降低，變更是必然的，如果單一職責(zé)原則遵守的好，當(dāng)修改一個功能時，可以顯著降低對其他功能的影響。

2、里氏替換原則

問題由來：
有一功能P1，由類A完成。現(xiàn)需要將功能P1進(jìn)行擴(kuò)展，擴(kuò)展后的功能為P，其中P由原有功能P1與新功能P2組成。
新功能P由類A的子類B來完成，則子類B在完成新功能P2的同時，有可能會導(dǎo)致原有功能P1發(fā)生故障。

解決方案：
當(dāng)使用繼承時，遵循里氏替換原則。類B繼承類A時，除添加新的方法完成新增功能P2外，
盡量不要重寫父類A的方法，也盡量不要重載父類A的方法。


里氏替換原則就是依賴于繼承和多態(tài)兩大特性。
簡單地說，就是父類能出現(xiàn)的地方子類就可以出現(xiàn)，
而且替換成子類也不會出現(xiàn)任何錯誤或者異常，
而使用者也無需知道是父類還是子類。
但是有子類的地方不一定適用于所有父類。

里氏替換原則通俗的來講就是：子類可以擴(kuò)展父類的功能，但不能改變父類原有的功能。

它包含以下4層含義：

 - 子類可以實(shí)現(xiàn)父類的抽象方法，但不能覆蓋父類的非抽象方法。
 - 子類中可以增加自己特有的方法。
 - 當(dāng)子類的方法重載父類的方法時，方法的前置條件（即方法的形參）要比父類方法的輸入?yún)?shù)更寬松。
 - 當(dāng)子類的方法實(shí)現(xiàn)父類的抽象方法時，方法的后置條件（即方法的返回值）要比父類更嚴(yán)格。
    

`重載（overload）：函數(shù)名相同,函數(shù)的參數(shù)列表不同(包括參數(shù)個數(shù)和參數(shù)類型)，
至于返回類型可同可不同。重載既可以發(fā)生在同一個類的不同函數(shù)之間，也可發(fā)生在父類子類的繼承關(guān)系之間，
其中發(fā)生在父類子類之間時要注意與重寫區(qū)分開。`

`重寫（override）：發(fā)生于父類和子類之間，指的是子類不想繼承使用父類的方法，
通過重寫同一個函數(shù)的實(shí)現(xiàn)實(shí)現(xiàn)對父類中同一個函數(shù)的覆蓋，因此又叫函數(shù)覆蓋。
注意重寫的函數(shù)必須和父類一模一樣，包括函數(shù)名、參數(shù)個數(shù)和類型以及返回值，只是重寫了函數(shù)的實(shí)現(xiàn)，這也是和重載區(qū)分開的關(guān)鍵。`

看上去很不可思議，因?yàn)槲覀儠l(fā)現(xiàn)在自己編程中常常會違反里氏替換原則，程序照樣跑的好好的。
所以大家都會產(chǎn)生這樣的疑問，假如我非要不遵循里氏替換原則會有什么后果？

后果就是：你寫的代碼出問題的幾率將會大大增加。

3、依賴倒置原則

定義：高層模塊不應(yīng)該依賴低層模塊，二者都應(yīng)該依賴其抽象；抽象不應(yīng)該依賴細(xì)節(jié)；細(xì)節(jié)應(yīng)該依賴抽象。

問題由來：類A直接依賴類B，假如要將類A改為依賴類C，則必須通過修改類A的代碼來達(dá)成。    
這種場景下，類A一般是高層模塊，負(fù)責(zé)復(fù)雜的業(yè)務(wù)邏輯；類B和類C是低層模塊，
負(fù)責(zé)基本的原子操作；假如修改類A，會給程序帶來不必要的風(fēng)險。

解決方案：將類A修改為依賴接口I，類B和類C各自實(shí)現(xiàn)接口I，
類A通過接口I間接與類B或者類C發(fā)生聯(lián)系，則會大大降低修改類A的幾率。

依賴倒置原則基于這樣一個事實(shí)：相對于細(xì)節(jié)的多變性，抽象的東西要穩(wěn)定的多。
以抽象為基礎(chǔ)搭建起來的架構(gòu)比以細(xì)節(jié)為基礎(chǔ)搭建起來的架構(gòu)要穩(wěn)定的多。
在java中，抽象指的是接口或者抽象類，細(xì)節(jié)就是具體的實(shí)現(xiàn)類，使用接口或者抽象類的目的是制定好規(guī)范和契約，
而不去涉及任何具體的操作，把展現(xiàn)細(xì)節(jié)的任務(wù)交給他們的實(shí)現(xiàn)類去完成。

依賴倒置原則的核心思想是面向接口編程。

class Newspaper implements IReader {
    public String getContent(){
        return "林書豪17+9助尼克斯擊敗老鷹……";
    }
}
class Book implements IReader{
    public String getContent(){
        return "很久很久以前有一個阿拉伯的故事……";
    }
}

class Mother{
    public void narrate(IReader reader){
        System.out.println("媽媽開始講故事");
        System.out.println(reader.getContent());
    }
}

public class Client{
    public static void main(String[] args){
        Mother mother = new Mother();
        mother.narrate(new Book());
        mother.narrate(new Newspaper());
    }
}

這樣設(shè)計后，無論以后怎樣擴(kuò)展Client類，都不需要再修改Mother類了，這只是一個簡單的例子，實(shí)際情況中，
代表高層模塊的Mother類將負(fù)責(zé)完成主要的業(yè)務(wù)邏輯，一旦需要對它進(jìn)行修改，引入錯誤的風(fēng)險極大。
所以遵循依賴倒置原則可以降低類之間的耦合性，提高系統(tǒng)的穩(wěn)定性，降低修改程序造成的風(fēng)險。

 依賴倒置原則的核心就是要我們面向接口編程，理解了面向接口編程，也就理解了依賴倒置。

 采用依賴倒置原則給多人并行開發(fā)帶來了極大的便利，比如上例中，原本Mother類與Book類直接耦合時，
 Mother類必須等Book類編碼完成后才可以進(jìn)行編碼，因?yàn)镸other類依賴于Book類。
 修改后的程序則可以同時開工，互不影響，因?yàn)镸other與Book類一點(diǎn)關(guān)系也沒有。
 參與協(xié)作開發(fā)的人越多、項(xiàng)目越龐大，采用依賴導(dǎo)致原則的意義就越重大。
 依賴倒置原則的核心就是要我們面向接口編程，理解了面向接口編程，也就理解了依賴倒置。

4、 接口隔離原則

定義：客戶端不應(yīng)該依賴它不需要的接口；一個類對另一個類的依賴應(yīng)該建立在最小的接口上。

問題由來：類A通過接口I依賴類B，類C通過接口I依賴類D，如果接口I對于類A和類B來說不是最小接口，
        則類B和類D必須去實(shí)現(xiàn)他們不需要的方法。

解決方案：將臃腫的接口I拆分為獨(dú)立的幾個接口，類A和類C分別與他們需要的接口建立依賴關(guān)系。也就是采用接口隔離原則。

一個接口代表一個角色，不應(yīng)當(dāng)將不同的角色都交給一個接口。
沒有關(guān)系的接口合并在一起，形成一個臃腫的大接口，這是對角色和接口的污染。

“不應(yīng)該強(qiáng)迫客戶依賴于它們不用的方法。接口屬于客戶，不屬于它所在的類層次結(jié)構(gòu)”這個說得很明白了，
再通俗點(diǎn)說，不要強(qiáng)迫客戶使用它們不用的方法，如果強(qiáng)迫用戶使用它們不使用的方法，

那么這些客戶就會面臨由于這些不使用的方法的改變所帶來的改變。

接口隔離原則的含義是：建立單一接口，不要建立龐大臃腫的接口，盡量細(xì)化接口，接口中的方法盡量少。
也就是說，我們要為各個類建立專用的接口，而不要試圖去建立一個很龐大的接口供所有依賴它的類去調(diào)用。

采用接口隔離原則對接口進(jìn)行約束時，要注意以下幾點(diǎn)：

1.接口盡量小，但是要有限度。對接口進(jìn)行細(xì)化可以提高程序設(shè)計靈活性是不掙的事實(shí)，
  但是如果過小，則會造成接口數(shù)量過多，使設(shè)計復(fù)雜化。所以一定要適度。

2. 為依賴接口的類定制服務(wù)，只暴露給調(diào)用的類它需要的方法，它不需要的方法則隱藏起來。
  只有專注地為一個模塊提供定制服務(wù)，才能建立最小的依賴關(guān)系。

3.提高內(nèi)聚，減少對外交互。使接口用最少的方法去完成最多的事情。
  運(yùn)用接口隔離原則，一定要適度，接口設(shè)計的過大或過小都不好。
  設(shè)計接口的時候，只有多花些時間去思考和籌劃，才能準(zhǔn)確地實(shí)踐這一原則。

這樣就能很好的滿足接口隔離原則了,調(diào)用者只能訪問它自己的方法,不能訪問到不應(yīng)該訪問的方法.

5、 迪米特法則

定義：一個對象應(yīng)該對其他對象保持最少的了解。

問題由來：類與類之間的關(guān)系越密切，耦合度越大，當(dāng)一個類發(fā)生改變時，對另一個類的影響也越大。

解決方案：盡量降低類與類之間的耦合。

自從我們接觸編程開始，就知道了軟件編程的總的原則：低耦合，高內(nèi)聚。
無論是面向過程編程還是面向?qū)ο缶幊?，只有使各個模塊之間的耦合盡量的低，才能提高代碼的復(fù)用率。
低耦合的優(yōu)點(diǎn)不言而喻，但是怎么樣編程才能做到低耦合呢？那正是迪米特法則要去完成的。

迪米特法則又叫最少知道原則，最早是在1987年由美國Northeastern University的Ian Holland提出。通俗的來講，就是一個類對自己依賴的類知道的越少越好。也就是說，對于被依賴的類來說，無論邏輯多么復(fù)雜，都盡量地的將邏輯封裝在類的內(nèi)部，對外除了提供的public方法，不對外泄漏任何信息。

迪米特法則還有一個更簡單的定義：只與直接的朋友通信。

首先來解釋一下什么是直接的朋友：每個對象都會與其他對象有耦合關(guān)系，
只要兩個對象之間有耦合關(guān)系，我們就說這兩個對象之間是朋友關(guān)系。耦合的方式很多，依賴、關(guān)聯(lián)、組合、聚合等。
其中，我們稱出現(xiàn)成員變量、方法參數(shù)、方法返回值中的類為直接的朋友，而出現(xiàn)在局部變量中的類則不是直接的朋友。
也就是說，陌生的類最好不要作為局部變量的形式出現(xiàn)在類的內(nèi)部。

值得注意的是：

    迪米特法則的初衷是降低類之間的耦合，由于每個類都減少了不必要的依賴，因此的確可以降低耦合關(guān)系。
    但是凡事都有度，雖然可以避免與非直接的類通信，但是要通信，必然會通過一個“中介”來發(fā)生聯(lián)系，
    例如例中，總公司就是通過分公司這個“中介”來與分公司的員工發(fā)生聯(lián)系的。過分的使用迪米特原則，
    會產(chǎn)生大量這樣的中介和傳遞類，導(dǎo)致系統(tǒng)復(fù)雜度變大。所以在采用迪米特法則時要反復(fù)權(quán)衡，既做到結(jié)構(gòu)清晰，又要高內(nèi)聚低耦合。

6.、開閉原則

定義：一個軟件實(shí)體如類、模塊和函數(shù)應(yīng)該對擴(kuò)展開放，對修改關(guān)閉。

問題由來：在軟件的生命周期內(nèi)，因?yàn)樽兓?、升級和維護(hù)等原因需要對軟件原有代碼進(jìn)行修改時，可能會給舊代碼中引入錯誤，
也可能會使我們不得不對整個功能進(jìn)行重構(gòu)，并且需要原有代碼經(jīng)過重新測試。

解決方案：當(dāng)軟件需要變化時，盡量通過擴(kuò)展軟件實(shí)體的行為來實(shí)現(xiàn)變化，而不是通過修改已有的代碼來實(shí)現(xiàn)變化。

開閉原則是面向?qū)ο笤O(shè)計中最基礎(chǔ)的設(shè)計原則，它指導(dǎo)我們?nèi)绾谓⒎€(wěn)定靈活的系統(tǒng)。開閉原則可能是設(shè)計模式六項(xiàng)原則中定義最模糊的一個了，
它只告訴我們對擴(kuò)展開放，對修改關(guān)閉，可是到底如何才能做到對擴(kuò)展開放，對修改關(guān)閉，并沒有明確的告訴我們。
以前，如果有人告訴我“你進(jìn)行設(shè)計的時候一定要遵守開閉原則”，我會覺的他什么都沒說，但貌似又什么都說了。因?yàn)殚_閉原則真的太虛了。

在仔細(xì)思考以及仔細(xì)閱讀很多設(shè)計模式的文章后，終于對開閉原則有了一點(diǎn)認(rèn)識。其實(shí)，我們遵循設(shè)計模式前面5大原則，
以及使用23種設(shè)計模式的目的就是遵循開閉原則。也就是說，只要我們對前面5項(xiàng)原則遵守的好了，設(shè)計出的軟件自然是符合開閉原則的，
這個開閉原則更像是前面五項(xiàng)原則遵守程度的“平均得分”，前面5項(xiàng)原則遵守的好，平均分自然就高，說明軟件設(shè)計開閉原則遵守的好；
如果前面5項(xiàng)原則遵守的不好，則說明開閉原則遵守的不好。

其實(shí)筆者認(rèn)為，開閉原則無非就是想表達(dá)這樣一層意思：用抽象構(gòu)建框架，用實(shí)現(xiàn)擴(kuò)展細(xì)節(jié)。

因?yàn)槌橄箪`活性好，適應(yīng)性廣，只要抽象的合理，可以基本保持軟件架構(gòu)的穩(wěn)定。而軟件中易變的細(xì)節(jié)，
我們用從抽象派生的實(shí)現(xiàn)類來進(jìn)行擴(kuò)展，當(dāng)軟件需要發(fā)生變化時，我們只需要根據(jù)需求重新派生一個實(shí)現(xiàn)類來擴(kuò)展就可以了。
當(dāng)然前提是我們的抽象要合理，要對需求的變更有前瞻性和預(yù)見性才行。

六大原則總結(jié)

說到這里，再回想一下前面說的5項(xiàng)原則，恰恰是告訴我們用抽象構(gòu)建框架，用實(shí)現(xiàn)擴(kuò)展細(xì)節(jié)的注意事項(xiàng)而已：
單一職責(zé)原則告訴我們實(shí)現(xiàn)類要職責(zé)單一；
里氏替換原則告訴我們不要破壞繼承體系；
依賴倒置原則告訴我們要面向接口編程；
接口隔離原則告訴我們在設(shè)計接口的時候要精簡單一；
迪米特法則告訴我們要降低耦合。
而開閉原則是總綱，他告訴我們要對擴(kuò)展開放，對修改關(guān)閉。

 最后說明一下如何去遵守這六個原則。對這六個原則的遵守并不是是和否的問題，而是多和少的問題，
也就是說，我們一般不會說有沒有遵守，而是說遵守程度的多少。任何事都是過猶不及，
設(shè)計模式的六個設(shè)計原則也是一樣，制定這六個原則的目的并不是要我們刻板的遵守他們，而需要根據(jù)實(shí)際情況靈活運(yùn)用。
對他們的遵守程度只要在一個合理的范圍內(nèi)，就算是良好的設(shè)計。我們用一幅圖來說明一下。

圖中的每一條維度各代表一項(xiàng)原則，我們依據(jù)對這項(xiàng)原則的遵守程度在維度上畫一個點(diǎn)，
則如果對這項(xiàng)原則遵守的合理的話，這個點(diǎn)應(yīng)該落在紅色的同心圓內(nèi)部；如果遵守的差，點(diǎn)將會在小圓內(nèi)部；
如果過度遵守，點(diǎn)將會落在大圓外部。一個良好的設(shè)計體現(xiàn)在圖中，應(yīng)該是六個頂點(diǎn)都在同心圓中的六邊形。

在上圖中，設(shè)計1、設(shè)計2屬于良好的設(shè)計，他們對六項(xiàng)原則的遵守程度都在合理的范圍內(nèi)；
設(shè)計3、設(shè)計4設(shè)計雖然有些不足，但也基本可以接受；
設(shè)計5則嚴(yán)重不足，對各項(xiàng)原則都沒有很好的遵守；
而設(shè)計6則遵守過渡了，設(shè)計5和設(shè)計6都是迫切需要重構(gòu)的設(shè)計。

最終的目的：設(shè)計出高內(nèi)聚低耦合的架構(gòu)

軟件架構(gòu)設(shè)計的目的簡單說就是在保持軟件內(nèi)在聯(lián)系的前提下，
分解軟件系統(tǒng)，降低軟件系統(tǒng)開發(fā)的復(fù)雜性，而分解軟件系統(tǒng)的基本方法無外乎分層和分割。
但是在保持軟件內(nèi)在聯(lián)系的前提下，如何分層分割系統(tǒng)，分層分割到什么樣的程度，并不是一件容易的事，
這方面有各種各樣的分解方法，比如：關(guān)注點(diǎn)分離，面向方面，面向?qū)ο螅嫦蚪涌?，面向服?wù)，依賴注入，以及各種各樣的設(shè)計原則等，

耦合性：也稱塊間聯(lián)系。指軟件系統(tǒng)結(jié)構(gòu)中各模塊間相互聯(lián)系緊密程度的一種度量。模塊之間聯(lián)系越緊密，其耦合性就越強(qiáng)，
       模塊的獨(dú)立性則越差。模塊間耦合高低取決于模塊間接口的復(fù)雜性、調(diào)用的方式及傳遞的信息

內(nèi)聚性：又稱塊內(nèi)聯(lián)系。指模塊的功能強(qiáng)度的度量，即一個模塊內(nèi)部各個元素彼此結(jié)合的緊密程度的度量。
       若一個模塊內(nèi)各元素（語名之間、程序段之間）聯(lián)系的越緊密，則它的內(nèi)聚性就越高。

所謂高內(nèi)聚是指一個軟件模塊是由相關(guān)性很強(qiáng)的代碼組成，只負(fù)責(zé)一項(xiàng)任務(wù)，也就是常說的單一責(zé)任原則。

對于低耦合，粗淺的理解是：一個完整的系統(tǒng)，模塊與模塊之間，盡可能的使其獨(dú)立存在。也就是說，
讓每個模塊，盡可能的獨(dú)立完成某個特定的子功能。模塊與模塊之間的接口，盡量的少而簡單