單一職責原則

Single Responsibility Principle（SRP）
每一個介面就承擔一個責任（或者說是一類的責任），儘量做到只有一個原因引起變化
ps:電話機通話的過程可以分為 ，撥打電話->通話->結束通話電話
這裡撥打 和 結束通話 都是物理層面的可以做一個介面
通話的過程，是通訊層面的可以是移動也可以是聯通，可以做一個介面

里氏替換原則

程式碼中有基類的地方，一定可以用子類去替換，當然，反過來不成立

依賴倒置原則

• 高層模組不依賴底層模組，兩者都應該依賴他的抽象類
• 抽象類不應該依賴細節
• 細節應該依賴抽象類

用java解釋

• 模組間的依賴通過抽象發生，實現類之間不發生直接的依賴關係，其依賴關係是通過
  介面或抽象類產生的；
• 介面或抽象類不依賴於實現類；
• 實現類依賴介面或抽象類。

介面隔離原則

• 客戶端不應該依賴他不需要的介面
• 類間的依賴關係要建立在最小的介面上

通俗的講就是簡化介面，一個介面中不要有過多的方法
ps: 比如一個介面中有10個方法，他們都是屬於同一個職責的，但是使用者許可權不一樣能用的方法不一樣，所以這個介面在 單一職責原則 中是合理的，但是他不符合介面隔離原則.

迪米特法則

一個物件應該對其他物件有最少的瞭解。
通俗地講，一個類應該對自己需要耦合或呼叫的類知道得最少，你（被耦合或調
用的類）的內部是如何複雜都和我沒關係，那是你的事情，我就知道你提供的這麼多public方法，我就呼叫這麼多，其他的我一概不關心。

• 類只和直接的朋友通訊：
  朋友類：出現在成員變數、方法的輸入輸出引數中的類稱為成員朋友類，而出現在方法體內部的類不屬於朋友類

• 朋友之間也需要有距離：
  一個類公開的public屬性或方法越多，修改時涉及的面也就越大，變更引起的風險擴散也就越大，所以要儘量少的釋出public 方法，多用private

• 是自己的就是自己的：
  如果一個方法放在本類中，既不增加類間關係，也對本類不產生負面影響，那就放置在本類中

開閉原則

一個軟體實體如類、模組和函式應該對擴充套件開放，對修改關閉