設計模式的六大原則有：（有些設計模式天生就符合這些原則，而有些設計模式可能會在特定情況下犧牲一些原則以獲得其他優勢）
Single Responsibility Principle：單一職責原則
Open Closed Principle：開閉原則
Liskov Substitution Principle：里氏替換原則
Law of Demeter：迪米特法則
Interface Segregation Principle：介面隔離原則
Dependence Inversion Principle：依賴倒置原則
把這六個原則的首字母聯合起來（兩個 L 算做一個）就是 SOLID （solid，穩定的），其代表的含義就是這六個原則結合使用的好處：建立穩定、靈活、健壯的設計。下面我們來分別看一下這六大設計原則：
1.單一職責原則（Single Responsibility Principle）
一個類應該只有一個發生變化的原因。如果一個類負責處理使用者輸入資料的驗證和資料庫操作，那麼這個類就違反了單一職責原則。因為使用者輸入資料的驗證和資料庫操作是兩個不同的功能，應該由兩個不同的類來負責
There should never be more than one reason for a class to change.
六大設計原則之單一職責原則（SRP）
2.開閉原則（Open Closed Principle）
一個軟體實體，如類、模組和函式應該對擴充套件開放，對修改關閉
Software entities like classes, modules and functions should be open for extension but closed for modification
六大設計原則之開閉原則（OCP）
3.里氏替換原則（Liskov Substitution Principle）
這個原則要求子類在被引用的地方能夠替代其父類，而不會引起意外的行為或破壞程式的邏輯。換句話說，對於使用基類型別的程式碼來說，如果替換成子類物件後程式的行為仍然是正確的，那麼這個子類就符合里氏替換原則。
Functions that use use pointers or references to base classes must be able to use objects of derived classes without knowing it.
六大設計原則之里氏替換原則（LSP）
4.迪米特法則（Law of Demeter）
迪米特法則要求在設計類的方法時，只應該呼叫以下物件的方法：
該物件本身
作為方法引數傳遞進來的物件
該物件直接建立的物件
該物件持有的成員物件
不應該直接呼叫全域性物件、透過靜態方法訪問的物件、以及從其它方法返回的物件。這樣做有助於降低類之間的耦合度，提高系統的靈活性和可維護性。
舉個例子，如果一個類的方法需要呼叫另一個物件的方法，最好透過引數將該物件傳遞進來，而不是直接在方法中建立或引用這個物件。這樣可以避免方法之間過度依賴，使得程式碼更加清晰、可讀、可維護。
Talk only to your immediate friends and not to strangers
六大設計原則之迪米特法則（LOD）
5.介面隔離原則（Interface Segregation Principle）
客戶端不應該依賴它不需要的介面：
這句話強調了在設計介面時應該避免將不相關或不需要的方法放在同一個介面中。如果一個客戶端只需要使用介面中的部分方法，但是這個介面定義了很多其他不需要的方法，那麼客戶端就不應該依賴於這個介面。這樣做可能會導致客戶端需要實現不必要的方法，增加了程式碼的複雜性和維護成本。
類間的依賴關係應該建立在最小的介面上：
這句話強調了在類與類之間建立依賴關係時，應該使用最小的介面，即只提供被依賴類所需的方法。這樣做可以降低類之間的耦合度，提高系統的靈活性和可維護性。如果一個類依賴於一個過大的介面，意味著它可能會受到不必要的影響，並且在介面發生變化時需要做出不必要的調整。
Clients should not be forced to depend upon interfaces that they don`t use.
The dependency of one class to another one should depend on the smallest possible.
六大設計原則之介面隔離原則（ISP）
6.依賴倒置原則（Dependence Inversion Principle）
上層模組不應該依賴底層模組，它們都應該依賴於抽象：
這句話強調了在系統設計中，高層模組（上層模組）和低層模組（底層模組）之間的依賴關係不應該直接存在，而是應該透過抽象來進行解耦。換句話說，高層模組和低層模組都應該依賴於抽象，而不是相互之間直接依賴。這樣做可以提高系統的靈活性和可維護性，因為改變底層模組的實現不會影響到上層模組。
抽象不應該依賴於細節，細節應該依賴於抽象：
這句話強調了在使用抽象時，抽象不應該依賴於具體的實現細節，而是應該讓具體的實現細節依賴於抽象。換句話說，抽象應該定義介面或者規範，而具體的實現細節則應該根據這個介面或規範來實現。這樣做有利於降低耦合度，提高程式碼的可擴充套件性和可維護性，同時也方便了程式碼的替換和重用。
High level modules should not depend upon low level modules. Both should depend upon abstractions.
Abstractions should not depend upon details. Details should depend upon abstractions.