定義：不要存在多于一個導(dǎo)致類變更的原因。通俗的說，即一個類只負責(zé)一項職責(zé)。
問題由來：類T負責(zé)兩個不同的職責(zé)：職責(zé)P1，職責(zé)P2。當由于職責(zé)P1需求發(fā)生改變而需要修改類T時，有可能會導(dǎo)致原本運行正常的職責(zé)P2功能發(fā)生故障。
解決方案：遵循單一職責(zé)原則。分別建立兩個類T1、T2，使T1完成職責(zé)P1功能，T2完成職責(zé)P2功能。這樣，當修改類T1時，不會使職責(zé)P2發(fā)生故障風(fēng)險；同理，當修改T2時，也不會使職責(zé)P1發(fā)生故障風(fēng)險。
遵循單一職責(zé)原的優(yōu)點有：
1. 可以降低類的復(fù)雜度，一個類只負責(zé)一項職責(zé)，其邏輯肯定要比負責(zé)多項職責(zé)簡單的多；
2. 提高類的可讀性，提高系統(tǒng)的可維護性；
3. 變更引起的風(fēng)險降低，變更是必然的，如果單一職責(zé)原則遵守的好，當修改一個功能時，可以顯著降低對其他功能的影響。
需要說明的一點是單一職責(zé)原則不只是面向?qū)ο缶幊趟枷胨赜械模灰悄K化的程序設(shè)計，都需要遵循這一重要原則。
定義：一個軟件實體如類、模塊和函數(shù)應(yīng)該對擴展開放，對修改關(guān)閉。
問題由來：在軟件的生命周期內(nèi)，因為變化、升級和維護等原因需要對軟件原有代碼進行修改時，可能會給舊代碼中引入錯誤，也可能會使我們不得不對整個功能進行重構(gòu)，并且需要原有代碼經(jīng)過重新測試。
解決方案：當軟件需要變化時，盡量通過擴展軟件實體的行為來實現(xiàn)變化，而不是通過修改已有的代碼來實現(xiàn)變化。
定義1：如果對每一個類型為 T1的對象 o1，都有類型為 T2 的對象o2，使得以 T1定義的所有程序 P 在所有的對象 o1 都代換成 o2 時，程序 P 的行為沒有發(fā)生變化，那么類型 T2 是類型 T1 的子類型。
定義2：所有引用基類的地方必須能透明地使用其子類的對象。
問題由來：有一功能P1，由類A完成。現(xiàn)需要將功能P1進行擴展，擴展后的功能為P，其中P由原有功能P1與新功能P2組成。新功能P由類A的子類B來完成，則子類B在完成新功能P2的同時，有可能會導(dǎo)致原有功能P1發(fā)生故障。
解決方案：當使用繼承時，遵循里氏替換原則。類B繼承類A時，除添加新的方法完成新增功能P2外，盡量不要重寫父類A的方法，也盡量不要重載父類A的方法。
里氏替換原則通俗的來講就是：子類可以擴展父類的功能，但不能改變父類原有的功能。它包含以下4層含義：
1. 子類可以實現(xiàn)父類的抽象方法，但不能覆蓋父類的非抽象方法。
2. 子類中可以增加自己特有的方法。
3. 當子類的方法重載父類的方法時，方法的前置條件（即方法的形參）要比父類方法的輸入?yún)?shù)更寬松。
4. 當子類的方法實現(xiàn)父類的抽象方法時，方法的后置條件（即方法的返回值）要比父類更嚴格。
定義：客戶端不應(yīng)該依賴它不需要的接口；一個類對另一個類的依賴應(yīng)該建立在最小的接口上。
問題由來：類A通過接口I依賴類B，類C通過接口I依賴類D，如果接口I對于類A和類B來說不是最小接口，則類B和類D必須去實現(xiàn)他們不需要的方法。
解決方案：將臃腫的接口I拆分為獨立的幾個接口，類A和類C分別與他們需要的接口建立依賴關(guān)系。也就是采用接口隔離原則。
很多人會覺的接口隔離原則跟之前的單一職責(zé)原則很相似，其實不然。其一，單一職責(zé)原則原注重的是職責(zé)；而接口隔離原則注重對接口依賴的隔離。其二，單一職責(zé)原則主要是約束類，其次才是接口和方法，它針對的是程序中的實現(xiàn)和細節(jié)；而接口隔離原則主要約束接口接口，主要針對抽象，針對程序整體框架的構(gòu)建。
采用接口隔離原則對接口進行約束時，要注意以下幾點：
1. 接口盡量小，但是要有限度。對接口進行細化可以提高程序設(shè)計靈活性是不掙的事實，但是如果過小，則會造成接口數(shù)量過多，使設(shè)計復(fù)雜化。所以一定要適度。
2. 為依賴接口的類定制服務(wù)，只暴露給調(diào)用的類它需要的方法，它不需要的方法則隱藏起來。只有專注地為一個模塊提供定制服務(wù)，才能建立最小的依賴關(guān)系。
3. 提高內(nèi)聚，減少對外交互。使接口用最少的方法去完成最多的事情。
運用接口隔離原則，一定要適度，接口設(shè)計的過大或過小都不好。設(shè)計接口的時候，只有多花些時間去思考和籌劃，才能準確地實踐這一原則。
定義：高層模塊不應(yīng)該依賴低層模塊，二者都應(yīng)該依賴其抽象；抽象不應(yīng)該依賴細節(jié)；細節(jié)應(yīng)該依賴抽象。
問題由來：類A直接依賴類B，假如要將類A改為依賴類C，則必須通過修改類A的代碼來達成。這種場景下，類A一般是高層模塊，負責(zé)復(fù)雜的業(yè)務(wù)邏輯；類B和類C是低層模塊，負責(zé)基本的原子操作；假如修改類A，會給程序帶來不必要的風(fēng)險。
解決方案：將類A修改為依賴接口I，類B和類C各自實現(xiàn)接口I，類A通過接口I間接與類B或者類C發(fā)生聯(lián)系，則會大大降低修改類A的幾率。
傳遞依賴關(guān)系有三種方式，以上的例子中使用的方法是接口傳遞，另外還有兩種傳遞方式：構(gòu)造方法傳遞和setter方法傳遞，相信用過Spring框架的，對依賴的傳遞方式一定不會陌生。
在實際編程中，我們一般需要做到如下3點：
1.低層模塊盡量都要有抽象類或接口，或者兩者都有。
2.變量的聲明類型盡量是抽象類或接口。
3.使用繼承時遵循里氏替換原則。
依賴倒置原則的核心就是要我們面向接口編程，理解了面向接口編程，也就理解了依賴倒置。
定義：一個對象應(yīng)該對其他對象保持最少的了解。
問題由來：類與類之間的關(guān)系越密切，耦合度越大，當一個類發(fā)生改變時，對另一個類的影響也越大。
解決方案：盡量降低類與類之間的耦合。
單一職責(zé)原則告訴我們實現(xiàn)類要職責(zé)單一；
里氏替換原則告訴我們不要破壞繼承體系；
依賴倒置原則告訴我們要面向接口編程；
接口隔離原則告訴我們在設(shè)計接口的時候要精簡單一；
開閉原則是總綱，他告訴我們要對擴展開放，對修改關(guān)閉。
迪米特法則告訴我們要降低耦合。
