1.單一職責原則2.里氏替換原則3.依賴倒置原則4.介面隔離原則5.迪米特法則6.開閉原則單一職責原則里氏替換原則依賴倒置原則介面隔離原則迪米特法則開閉原則1.單一職責原則適用於介面、類、方法，要求一個介面或類只由一個原因引起變化，也就是一個介面或類只有一個職責，它就負責一件事。讓我們舉個慄子在以... ...
- 單一職責原則
- 里氏替換原則
- 依賴倒置原則
- 介面隔離原則
- 迪米特法則
- 開閉原則
1.單一職責原則
適用於介面、類、方法，要求一個介面或類只由一個原因引起變化，也就是一個介面或類只有一個職責，它就負責一件事。
讓我們舉個慄子

在以上的介面中，定義了撥號、通話、掛掉，三個行為，但通話屬於數據傳輸，與撥號、掛掉職責不同，所以將介面改成如下

單一職責優勢：
1. 類的複雜度降低，實現什麼職責都有清晰明確的定義；
2. 可讀性提高，複雜性降低
3. 可維護性提高
4. 變更引起的風險降低，擴展性、維護性增強
對於介面，設計時一定要做到單一，但對於實現類就需要多方面考慮，儘量做到只有一個原因引起變化。生搬硬套單一職責會引起類的劇增，給維護帶來很多麻煩，人為增加系統複雜性。
2.里氏替換原則
首先讓我們來總結一下java中繼承的優點：
1. 代碼共用、減少創建類的工作量
2. 提高代碼重用性、擴展性
3. 提高項目的開放性
java中繼承的缺點：
1. 侵入性，一旦繼承，就必須擁有父類所有屬性和方法
2. 降低靈活性，子類約束多
3. 增強耦合性(代碼重構)
里氏替換原則兩種定義：
1. 如果對每一個類型為S的對象s1，都有類型為T的對象t1，使得以T定義的所有程式P在所有的對應s1都代換成t1時，程式P的行為沒有發生變化，那麼類型S是類型T的子類型。
2. 所有引用基類的地方必須能透明的使用其他子類的對象
通俗來講，只要父類能出現的地方子類就能出現，而且替換為子類也不會產生任何錯誤或者異常，使用者可能根本不需要知道是父類還是子類。但相反就不行，有子類出現的地方，父類未必能適應。
規範：
1. 子類必須完全實現父類的方法
2. 子類可以有自己的特性
3. 覆蓋或實現父類方法時參數可以被放大
4. 覆寫或實現父類的方法時輸出結果可以被縮小
3.依賴倒置原則
相信做web的朋友並不陌生，spring的其中一個核心就是依賴倒置。
含義
1. 高層模塊不應該依賴底層模塊，兩者都應該依賴其抽象
2. 抽象不應該依賴細節
3. 細節應該依賴抽象
依賴倒置在java中的表現：
1. 模塊間的依賴通過抽象發生，實現類之間不發生直接的依賴關係，其依賴關係是通過介面或抽象類產生的
2. 介面或抽象類不依賴實現類
3. 實現類依賴介面或者抽象類
依賴的三種寫法：
1. 構造函數傳遞依賴對象
2. Setter方法傳遞依賴對象
3. 介面聲明依賴對象
//構造傳遞方式
public interfice IDriver{
//一個會開車的老司機
public void drive();
}
public class Driver implements IDrvier{
private ICar car;
//構造註入
public Driver(ICar _car){
this.car = _car;
}
//奔跑吧,野驢
public void drive(){
this.car.run();
}
}
//Setter方法傳遞方式
public interface IDriver{
//設置車的型號
public void setCar(ICar car);
//一個會開車的老司機
public void drive();
}
public class Driver implements IDrvier{
private ICar car;
public void setCar(ICar car){
this.car = car;
}
//奔跑吧,野驢
public void drive(){
this.car.run();
}
}
}
依賴倒置的本質就是通過抽象(介面或抽象類)使個各類或模塊的實現彼此獨立，不互相影響，實現模塊間的松耦合
規則：
1. 每個類儘量有介面或抽象類，或者兩者兼具
2. 變數的錶面類型儘量是介面或者抽象類
3. 任何類都不應該從具體類派生
4. 儘量不要覆寫基類方法【如果基類是抽象類，而且這個方法已經實現了，子類儘量不要覆寫。類間依賴的是抽象，覆寫了抽象方法，對依賴的穩定性會產生一定的影響】
5. 結合里氏替換原則使用
4.介面隔離原則
首先明確一下介面
* 實例介面(Object Interface): 在java中聲明一個類，然後用new產生一個實例，它是對一個類型的事物的描述，這就是一種介面
* 類介面(Class Interface): java中經常使用的關鍵字定義的介面
那什麼又叫隔離？下麵給出兩種定義【本質上是要求介面的純凈和細化】
* 客戶端不應該依賴它不需要的介面
* 類間的依賴關係應該建立在最小的介面上
比如我們來客串一次星探，挖掘漂亮妹紙

以上是對漂亮妹紙最基本的要求，但審美的觀點各有不同，每個時代對美的概念也不一樣，以上設計顯得不足以應對了，這可咋整？
以上的介面中，設計的過於龐大了些，容納了一些可變的因素，星探們應該依賴於具有部分特質的妹紙，然而我們將這些特質都封裝了起來，放入一個介面，屬於過度封裝

將原來的介面拆分為兩個，一種是外形漂亮的妹紙，一種是氣質型的妹紙
- 將一個臃腫的介面變更為兩個獨立的介面鎖依賴的原則就是介面隔離原則。
- 介面是設計時對外提供的契約，通過分散定義多個介面，可以預防未來變更的擴散，提高系統靈活性和維護性
介面隔離原則是對介面進行規範約束
- 介面儘量小【根據介面隔離原則拆分介面時，首先必須滿足單一職責原則】
- 介面高內聚【提高介面、類、模塊處理能力；減少對外交互】
- 定製服務【單獨為一個個體提供優良的服務；要求：只提供訪問中需要的方法】
- 介面設計是有限度的【根據項目具體情況進設計】
介面隔離原則是對介面的定義，同時也是對類的定義，介面和類儘量使用原子介面或原子類來組裝。原子的劃分可以根據以下規則衡量：
- 一個介面只服務於一個子模塊或者業務邏輯
- 通過業務邏輯壓縮介面中的public方法，介面時常回顧，儘量讓介面精簡而拒絕臃腫
- 已經被污染的介面，儘量去修改，若變更風險較大，則採用適配器模式進行轉化處理
- 瞭解手中項目的具體環境，拒絕盲從
5.迪米特法則
迪米特法則也被稱為最少知識原則：一個對象應該對其他對象有最少的瞭解。
一個類應該對自己需要耦合或調用的類知道得最少，被耦合或調用的類內部的如何複雜都不管，只管對方提供的方法和自己調用的就行。
迪米特法則對低耦合提出了明確要求：
只和直接的朋友交流
public class void main(String[] args){ Teacher teacher = new Teacher(); tacher.commond(new GroupLeader()); }如上設計中，teacher的直接對象只有GroupLeader
朋友類的定義：出現在成員變數、方法的輸入輸出參數中的類稱為成員朋友類，而出現在方法體內部的類不屬於朋友類，而Girl就算出現在commond方法體內部，因此不屬於Teacher類的朋友類。
迪米特法則告訴我們一個類只和朋友類交流，但剛纔定義的commond方法卻與gril類有了交流，聲明瞭一個List<Grils>動態數組，也就與陌生的類Girl有了交流，破壞了Teacher的健壯性。
方法是類的一個行為，類竟然不知道自己的行為與其他類產生依賴關係，這是不允許的，嚴重違反了迪米特法則。做如下修改。

對設計進行簡單的修改，降低了系統間耦合，提高健壯性
一個類只和朋友交流，不與陌生類交流，不要出現方法鏈且每一個方法返回類型都相同的情況，類與類之間的關係是建立在類間的，而不是方法間，儘量不引入一個類中不存在的對象，當然JDK提供的除外朋友間也是有距離的（每個方法訪問許可權儘量小）
一個類似安裝嚮導的程式，下一步->下一步....
每次是否需要進行下一步操作、以及操作調用都在InstallSoftWare類中控制，顯然是有問題的，因為耦合變得異常牢固，對此設計進行以下改動

將每次是否需要進行下一步操作、以及操作調用都放在Wizard，且三次操作的方法均為私有，僅提供installWizard()方法給調用者
*儘量不要對外公佈太多public方法和非靜態public變數，儘量內斂，多使用private、package-private、protected等訪問許可權是自己的就是自己的
如果一個方法放在本類中，既不增加類間關係，也不對本類產生負面影響，可以放置在本類中
謹慎使用serializable
核心：迪米特原則核心觀念就是類間解耦，弱耦合，只有弱耦合了以後，類的復用率才能提高。其要要求的結果就是產生了大量的中轉或跳轉類，導致系統的複雜性提高，同時也為維護帶來了難度。使用時需要反覆權衡，做到結構清晰，高內聚，低耦合。
6.開閉原則
定義：一個軟體實體如類、模塊、函數應該對擴展開發，對修改關閉。
軟體實體(邏輯劃分的模塊、抽象和類、方法)應該通過擴展來實現變化，而不是通過修改已有的代碼來實現變化。
產品的生命周期內都會發生變化，所以在設計時儘量適應這些變化，提高穩定性和靈活性。
讓我們舉個慄子：
圖書城圖書管理中查看書籍信息

但由於某種原因，所有數據需要打折計算，應用開閉原則，不對原有介面代碼進行更改的情況下，做如下設計

增加一個子類，覆寫了getPrice()；調用時改用OffNovelBook類產生新對象。
變化歸納：
- 邏輯變化
- 只改變一個邏輯，不涉及其他模塊(eg: a+b+c => abc) ，可以通過修改原有類中方法的方式來完成，前提是所有依賴或關聯都按照相同的邏輯處理
- 子模塊變化
- 一個模塊的變化必然影響其他模塊，特別是一個低層次的模塊變化必然引起高層模塊的變化，因此通過擴展完成變化時，高層模塊的修改是必然的
- 可見視圖的變化
開閉原則的重要性體現：
1. 版本迭代測試
2. 提高復用性
3. 提高可維護性
4. 面向對象開發的要求
如何使用開閉原則？
抽象約束
通過介面或抽象類可以約束一組可能變化的行為，並且能夠實現對擴展開發。
- 通過介面或者抽象類約束擴展，對擴展進行邊界限定，不允許出現在介面或抽象類中不存在的public方法
- 參數類型、引用對象儘量使用介面或抽象類
- 抽象層儘量保持穩定，一旦確定即不允許修改
元數據(metadata)控制模塊行為
儘量使用元數據(配置參數)來控製程序的行為，減少重覆開發。
制定項目章程
封裝變化(受保護的變化，找出預計有變化或不穩定的點，為其創建穩定的介面)
- 將相同的變化封裝到一個介面或抽象類中
- 將不同變化封裝到不同介面或抽象類中，不應該有兩個不同的變化出現在同一個介面或抽象類中
