這六大原則任何面向對象的語言都應該遵守的，要想讓你的代碼易擴展高服用就儘量去滿足這六大原則吧，不一定嚴格按照某種設計模式，但是如果你的代碼符合這六大原則，那麼你的代碼就是好代碼了，好的代碼不一定是嚴格按照設計模式寫的代碼。
單一職責原則（SRP）
Single Responsibility Principle，單一職責原則。
定義：不要存在多於一個導致類變更的原因。通俗的說，即一個類只負責一項職責。
優點：
- 可以降低類的複雜度，一個類只負責一項職責，邏輯簡單；
- 提高類的可讀性，提高系統的可維護性；
- 變更引起的風險降低，變更是必然的。
SRP其實也蘊含着深沉的人生智慧——任何事情要想做好就必須要專心致志地做。
里氏替換原則（LSP）
Liskov Substituition Principle，里氏替換原則。
定義：子類可以擴展父類的功能，但不能改變父類原有的功能。
當使用繼承時，遵循里氏替換原則。子類繼承父類時，除添加新的方法完成新增功能外，儘量不要重寫父類的方法，也儘量不要重載父類的方法。
依賴倒置原則（DIP）
Dependence Inversion Principle，依賴倒置原則。
定義：高層模塊不應該依賴低層模塊，二者都應該依賴其抽象；抽象不應該依賴細節；細節應該依賴抽象。
例如，業務邏輯層相對於數據層是高層模塊，因爲業務邏輯層需要調用數據層去連接數據庫，但是要做到可擴展高複用，儘量不要讓業務邏輯層依賴數據層（如數據庫類型mysql,pgsql），可以在數據層抽象出一個接口(如pdo)，讓業務邏輯層依賴於這個抽象接口(統一操作數據庫方法名)。
示例：
interface DB{
public function connect();
public function add();
public function update();
public function query();
public function del();
}
class Mysql implements DB{
}
class Sqlite implements DB{
}開放封閉原則（OCP）
Open-Close Principle，開-閉原則。
定義：一個軟件實體如類、模塊和函數應該對擴展開放，對修改關閉。
場景：在軟件的生命週期內，因爲變化、升級和維護等原因需要對軟件原有代碼進行修改時，可能會給舊代碼中引入錯誤，也可能會使我們不得不對整個功能進行重構，並且需要原有代碼經過重新測試。
建議：當軟件需求變化時，儘量通過擴展軟件實體的行爲來實現變化，而不是通過修改已有的代碼來實現變化。
接口隔離原則（ISP）
Interface Segregation Principle，接口隔離原則。
定義：客戶端不應該依賴它不需要的接口；一個類對另一個類的依賴應該建立在最小的接口上。
注意：
- 接口儘量小，但是要有限度。對接口進行細化可以提高程序設計靈活性 是不掙的事實，但是如果過小，則會造成接口數量過多，使設計複雜化。所以一定要適度。
- 爲依賴接口的類定製服務，只暴露給調用的類它需要的方法，它不需要的方法則隱藏起來。只有專注地爲一個模塊提供定製服務，才能建立最小的依賴關係。
- 提高內聚，減少對外交互。使接口用最少的方法去完成最多的事情。
迪米特法則（LKP）
Law of Demeter or Least Knowlegde Principle（LoD or LKP），迪米特法則或最少知識原則。這個原則首次在Demeter系統中得到正式運用，所以定義爲迪米特法則。它講的是"一個對象應當儘可能少的去了解其他對象"。也就是又一個關於如何松耦合（Loosely-Coupled）的法則。
定義：一個對象應該對其他對象保持最少的瞭解。
場景：類與類之間的關係越密切，耦合度越大，當一個類發生改變時，對另一個類的影響也越大。
簡單的理解就是高內聚，一個類儘量減少對其他對象的依賴，並且這個類的方法和屬性能用私有的就儘量私有化。
注意：
- 只與直接的朋友通信，不要和陌生人說話。
- 過分的使用該原則，將導致系統複雜度變大。所以在採用迪米特法則時要反覆權衡，既做到結構清晰，又要高內聚低耦合。