以下所有原則的描述對於已經實操過類似圖書管理小專案的盆友會很好理解（大佬請忽略此文哈哈）

一、單一職責原則

一個類只負責一個功能

• 當一個類的方法足夠少也會在方法級別上實現各司其責（比如當在類級別上成本較高的時候）
• 當業務程式碼邏輯很簡單時候，才可以違反該原則

二、介面隔離原則

一個classA通過介面implementC依賴於classB，那麼classB裡面最好不要有A用不到到的殭屍方法

• 就是說，一個類對另一個類的依賴應該建立在最小介面上，減少殭屍程式碼
• 實際操作就是把一個大介面拆分為幾個小介面，然後分別按需要建立依賴關係

三、依賴倒轉原則

1.高層模組不依賴於底層模組，而都應該依賴於其抽象（介面、抽象類）

2.細節（具體的實現類）依賴抽象

3.核心思想： 面向介面程式設計，用介面制定規範

• 建立依賴的三種常見方式：
• 介面套娃
• 構造器
• setter()方法
• 遵循里氏替換

四、 里氏替換

提出的背景或叫做解決的問題

繼承其實增加了程式耦合度子類最好不要重寫繼承的父類方法，這樣會破壞其他子類的繼承性，如果迫不得已要修改，可以提升原來的子類，讓原父類和其要重寫它方法的子類共同繼承一個更上層抽象的基類，用依賴、聚合、耦合關係代替繼承

五、開閉原則

六、迪米特法則（最少依賴法則）

說白了就是誰的事，就在誰自己那裡解決，對外只暴露方法

• 一個物件物件其所依賴的物件應該保持最低的瞭解
• 被依賴的類不不關邏輯多複雜，都應該除了暴露public方法之外，剩餘的都封裝在自己類的內部
• 類之間關係越大，耦合度越高
• 或者說之和直接朋友（注意是接著盆友！！！）通訊，不要跨級

朋友：存在耦合關係的（組合，繼承，依賴，聚合。。。）
根據不同的耦合關係，分為一下兩種：
直接盆友： 存在在類中的成員變數、引數、方法返回值
非直接朋友： 現在在區域性變數

• 陌生的類最好不要以區域性變數的形式出現在類的內部

合成複用原則

• 說白了就是多用聚合/合成 ，少繼承

小結

• 原則其實都是為了降低耦合
• 把需要改變的部分獨立出來，別和不變的混一起
• 面向介面，而不是面向具體實現