單一職責原則

一個類應當只負責一項職責，在業務邏輯簡單的情況下 也可以一個方法負責一項職責

優點

降低類的複雜度；
提高類的可讀性，可維護性；
降低變更類引起的風險

注意事項

在業務邏輯非常簡單的情況下，類會增多；所以可以在程式碼級違反單一職責原則。
只有類中方法數量足夠少，可以在方法級別保持單一職責原則

---

介面隔離原則(Interface Segregation Principle)

具體類不應該依賴它不需要的介面，即一個類對另一個類的依賴應該建立在最小的介面上
例如A類實現介面I，B類實現介面I，C類實現介面I；如圖
B類只需要m1 m2 m3方法，C類只需要 m4 m5方法，但被迫把介面的所有方法都實現了。

對 I 介面進行拆分成多個小介面
I1 介面宣告 m1 m2 m3方法，I2 介面宣告 m3 m4方法
A類實現 I1 介面 I2 介面；B類實現 I1 介面；C類實現 I2介面;
這樣就避免子類強迫實現不需要的介面方法，減少方法的宣告，提高類的可讀性，可維護性；
充分利用的Java的多實現

---

依賴倒轉(倒置)原則(Interface Segregation Principle)

高層模組不應該依賴低層模組，二者都應該依賴其抽象；
抽象不應該依賴細節，細節應該依賴抽象；
依賴倒轉(倒置)的中心思想是面向介面程式設計；
相對於細節的多變性，抽象的東西要穩定的多；
以抽象為基礎搭建的架構比以細節為基礎的架構要穩定的多；
在java中，抽象指的是介面或抽象類，細節就是具體的實現類；

使用：

注意事項：

低層模組儘量都要有抽象類或介面，或者兩者都有，程式穩定性更好.
變數的宣告型別儘量是抽象類或介面, 這樣我們的變數參照和實際物件間，就存在一個緩衝層，利於程式擴充套件和優化
繼承時遵循里氏替換原則

---

里氏替換原則(Liskov Substitution Principle)

任何基礎類別可以出現的方法，在子類也應該可以出現
在繼承父類別時，對於父類別中已經定義好的結構方法，不應該對其進行重寫；

如上圖所示；父類別(Base)中有add()方法；且已經實現好的業務邏輯；但子類(Sub)對其重寫了；
使得父類別的原有業務邏輯發生了改變;

注意事項：

繼承再給程式帶來便利的同時，也帶來了弊端；繼承會對程式有侵入性，
比如一個類被其他類所繼承，當這個類的所需要修改時，必選要考慮到所有子類，
會不會因為父類別的修改而可能產生故障；
再繼承父類別，不要對父類別定義好的演演算法骨架進行重寫；

---

開閉原則(Open Closed Principle)

對擴充套件開放，對修改關閉；在程式需要進行擴充套件的時候，不去修改原有的程式碼，而是擴充套件原有的程式碼；
程式設計中遵循其它原則，以及使用設計模式的目的就是遵循開閉原則。

如下圖所示；現在需要做一個繪製圖形的功能，有矩形，圓形；
由此可以定義好一個基礎類別，宣告抽象方法由子類實現；

下面需要再增加一個繪製三角形的類；由此只需要再定義一個三角形的類(Triangle)去繼承繪製圖形的基礎類別(Drawing)，然後實現抽象方法即可;
完全不需要去改動原有的程式碼，即可延伸一個功能；

注意事項：

在使用的時候，應當用基礎類別(Drawing)作為變數型別；滿足 依賴倒轉(倒置)原則(面向介面或抽象類程式設計)

---

迪米特法則(Demeter Principle)最少知道原則

一個物件應該對其他物件保持最少的瞭解；
類與類關係越密切，耦合度越大；
即一個類對自己依賴的類知道的越少越好。也就是說，對於被依賴的類不管多麼複雜，都儘量將邏輯封裝在類的內部。對外除了提供的public 方法，不對外洩露任何資訊

即A類參照B類，B類中的定義好的業務邏輯方法，只對本類使用的，不應該使用 piblic修飾符，而本類中的 public修飾的方法，再去呼叫本類中其他修飾符的方法。

---

合成複用原則

原則是儘量使用合成/聚合的方式，而不是使用繼承；
如果僅僅只是使用某個類的一些方法，不應該去繼承這個類

如下一個類，其他類只是想用其中的某些方法；如果繼承，顯然耦合度很大；

可以使用 合成/聚合的方式 列如：

以上只是簡單的程式碼演示，實際情況因根據專案而定。

---

設計原則核心思想

• 找出應用中可能需要變化之處，把它們獨立出來，不要和那些不需要變化的代
  碼混在一起。
• 針對介面程式設計，而不是針對實現程式設計。
• 為了互動物件之間的鬆耦合設計