在所有的設計模式開篇中，總是說一個好的架構，或多或少都會有設計模式的出現。當然或多或少也會使用設計模式的相關原則： SOLID+迪米爾原則 1.優化代碼的第一步：單一職責原則 S:單一職責鏈原則：英文名稱為Single Responsibility Principle（SRP） 定義：就一個類而言， ...
在所有的設計模式開篇中，總是說一個好的架構，或多或少都會有設計模式的出現。當然或多或少也會使用設計模式的相關原則：
SOLID+迪米爾原則
1.優化代碼的第一步：單一職責原則
S:單一職責鏈原則：英文名稱為Single Responsibility Principle（SRP）
定義：就一個類而言，應該僅有一個引起它變化的原因。通俗來說：一個類中應該有一組相關性很高的函數、數據的封裝。但是在設計模式之禪中說這個說法的爭議比較大，因為單一職責的劃分界限並不是那麼清晰的。就像明明知道資料庫設計的時候要保持一條記錄的原子性，但是為了方便後期操作的時候，不需要進行表連接而快速的獲取到數據，會出現部分冗餘的欄位。
2.讓程式更穩定、更靈活的：開閉原則
O:開閉原則：英文名稱為：Open Close Principle（OCP），它是Java裡面最基礎的設計原則：
定義：軟體中的對象（類、模塊、函數等）應該對於擴展是開放的，但是對於修改是封閉的。
軟體開發中最讓人煩惱的不是產品設計出來的功能不能實現，而是實現出來之後，下個版本要對本功能進行修改。但是如果我們修改原先的代碼不能保證原先軟體模塊的正確性。如果我們開發的是第三方的Jar包，已經將jar給其它客戶了，下個版本更新的時候要讓用戶所有用到jar文件的地方都要修改這很明顯是十分不合理的，此時開閉原則顯得非常重要。
3.構建擴展性更好的系統：里氏替換原則
L:里氏替換原則：英文名稱為：Liskov Substitution Principle（LSP）
定義：所有引用基類的地方必須能透明的使用子類的對象。
面向對象三大特點：封裝、繼承、多態。李氏替換原則依賴於繼承與多態。通俗的講：只要父類能出現的地方，其子類一定可以出現，而且替換成子類也不會產生任何異常和錯誤，調用者根本就不需要知道當前調用的對象是子類還是父類。反之則不一定成立，有子類出現的地方，父類未必能適應。總結兩個字就是：抽象。
里氏替換原則的核心就是抽象，抽象又依賴於繼承這個特性。在OOP編程中：繼承的優缺點相當明顯：
優點：
1）代碼重用，減少創建類的成本，每個子類都擁有父類的屬性和方法
2）子類和父類基本相似，但是又比父類多了自己的特征
3）提高代碼的可擴展性
繼承的缺點：
從側面上看，繼承的優點基本上也就是它的缺點：
1）繼承是侵入式的，只要繼承就必須擁有父類的所有屬性和方法。（連拒絕接收遺產的資格都沒有）
2）因為子類繼承了父類屬性和方法，可能導致子類代碼冗餘。
開閉原則和里氏替換原則是相互依靠的，通過里氏替換來達到對擴展開放，對修改關閉的效果。
4.系統有更高的靈活性：介面隔離原則
I：介面隔離：InterfaceSegregation Principle（ISP）
定義：類間的依賴關係應該建立在最小的介面上。通俗的講：讓客戶端依賴的介面儘可能的小
5.讓項目擁有變化的功能：依賴倒置原則
D:依賴倒置：Dependence Inversion Principle（DIP）重點在解耦上面
定義：模塊間的依賴通過抽象發生，實現類之間不發生直接的依賴關係，其依賴關係是通過介面和抽象類產生的。
更好的擴展性：迪米特原則
6.迪米特原則：Law of Demeter（LOD）
定義：一個對象應該對其它對象有最少的瞭解。通俗的說，一個類對自己需要耦合或者調用的類知道的最少，類的內部如何實現與調用者或者依賴者沒有關係，調用者或者依賴者只需要知道它需要的方法即可，其它的一概不用管。類與類之間的關係越密切，耦合度越大，當一個類放生改變的時候，對另一個類影響也越大。
