設計模式六大基本原則 1.單一職責原則 英文：Single Responsibility Principles,縮寫SRP 定義：就一個類而言，應該僅有一個引起它變化的原因。 理解：例如兩個完全不一樣的功能就不應該放在一個類中。一個類總應該是一組相關性很高的函數，數據的封裝。 對應一個類，不求功能面 ...
設計模式六大基本原則
1.單一職責原則
英文：Single Responsibility Principles,縮寫SRP 定義：就一個類而言，應該僅有一個引起它變化的原因。 理解：例如兩個完全不一樣的功能就不應該放在一個類中。一個類總應該是一組相關性很高的函數，數據的封裝。 對應一個類，不求功能面面俱到，只求能把一件事做好2.開閉原則
英文：Open Close Principle，縮寫OCP 定義：對於擴展是開放的，對於更改是封閉的。就是說軟體實體（類、模塊、函數等等）應該可以擴展，但是不能修改。 理解：在軟體的生命周期中，因為變化，升級維護等原因需要對軟體原有代碼進行修改時，可能會將錯誤引入源碼已經經過測試的沒有錯誤的舊代碼中，造成以前沒有錯誤的代碼錯誤。因此，當軟體需要變化時，我們應該儘量通過擴展的方式來實現變化，而不是通過修改已有代碼來實現。 實現開放封閉原則的關鍵就是抽象。對應已存在的實現類對應修改時封閉的，但是心的實現類可以通過覆蓋父類的介面應對變化。3.里氏替換原則
英文：Liskov Substitution Principle，縮寫LSP 定義：所有引用基類的地方必須能透明的使用其子類的對象 理解：只要父類能出現的地方子類就可以出現，而且替換為子類不會產生任何錯誤或異常，使用者根本不需要知道是父類還是子類。但是，反過來就不行了，有子類出現的地方，父類未必能適應。總結起來就是：抽象。4.依賴倒置原則
英文：Dependence Inversion Principle，縮寫DIP 定義：高層模塊不應該依賴底層模塊，兩個都應該依賴抽象；抽象不應該依賴細節，細節應該依賴抽象。 抽象是指介面或抽象類，兩者都是不能直接被實例化的；細節就是實現類，實現介面或繼承抽象類而產生的類就是細節，其特點是可以實例化，也就是可以加上一個關鍵字 new 產生一個對象。高層模塊就是調用端，底層模塊就是具體實現類。理解：這個原則的精髓就是，面向介面編程，或者說面向抽象編程，這裡的抽象是指介面或者抽象類。依賴倒轉原則是開放封閉原則實現的手段，是抽象的最好規範。依賴抽象，而不依賴具體實現。
5.介面隔離原則
英文：Interface Segregation Principle，縮寫ISP 定義：客戶端不應該依賴它不需要的介面，即類間的依賴關係應該建立在最小介面上。 理解：就是將非常龐大，臃腫的介面拆分成更小的和更具體的介面(這個和單一職責有點像只不過這個是介面)，這樣使用者只需要知道他們感興趣的方法就行。這樣做可以使系統擁有更低的耦合性、更高的靈活性。這個原則說白了就是，讓客戶端依賴的介面儘可能的小。6.迪米特原則
英文：Law of Demeter，縮寫LOD 定義：這個原則也叫最少知識原則：一個對象應該對其它對象有最少的瞭解。 理解：這個原則有一個英文解釋就是說 Only talk to your immedate friends，翻譯就是只和直接的朋友通信。什麼是直接朋友？每個對象都必然會與其他對象有耦合關係，兩個對象直接的耦合就成為朋友關係，這種類型有很多，如組合，聚合，依賴等。 調用者或者依賴者只要知道它需要的方法即可，至於方法是如何實現的，實現方法的類需要做什麼，都不需要知道。知道的越少耦合度約低，當一個類發生變化的時候，對另一個類的影響越小。就像現實中的找中介租房，我們只關係房間的面積和租金，讓中介將符合要求的房子提供給我們就行了。
