核心：解耦和增強內聚性（高內聚，低耦合）
說明：就乙個類而言，應該只專注於做一件事和僅有乙個引起它變化的原因。所謂職責，我們可以理解他為功能，就是設計的這個類功能應該只有乙個，而不是兩個或更多。也可以理解為引用變化的原因，當你發現有兩個變化會要求我們修改這個類，那麼你就要考慮撤分這個類了。因為職責是變化的乙個軸線，當需求變化時，該變化會反映類的職責的變化。
使用srp注意點：
1、乙個合理的類，應該僅有乙個引起它變化的原因，即單一職責；
2、在沒有變化徵兆的情況下應用srp或其他原則是不明智的；
3、在需求實際發生變化時就應該應用srp等原則來重構**；
4、使用測試驅動開發會迫使我們在設計出現臭味之前分離不合理**；
5、如果測試不能迫使職責分離，僵化性和脆弱性的臭味會變得很強烈，那就應該用facade或proxy模式對**重構；srp優點：消除耦合，減小因需求變化引起**僵化。
核心：要依賴於抽象，不要依賴於具體的實現
優點：使用傳統過程化程式設計所建立的依賴關係，策略依賴於細節，這是糟糕的，因為策略受到細節改變的影響。依賴倒置原則使細節和策略都依賴於抽象，抽象的穩定性決定了系統的穩定性。
怎樣做到依賴倒置？
以抽象方式耦合是依賴倒轉原則的關鍵。抽象耦合關係總要涉及具體類從抽象類繼承，並且需要保證在任何引用到基類的地方都可以改換成其子類，因此，黎克特制代換原則是依賴倒轉原則的基礎。
在抽象層次上的耦合雖然有靈活性，但也帶來了額外的複雜性，如果乙個具體類發生變化的可能性非常小，那麼抽象耦合能發揮的好處便十分有限，這時可以用具體耦合反而會更好。
層次化：所有結構良好的物件導向構架都具有清晰的層次定義，每個層次通過乙個定義良好的、受控的介面向外提供一組內聚的服務。
依賴於抽象：
建議不依賴於具體類，即程式中所有的依賴關係都應該終止於抽象類或者介面。
盡量做到：
1、任何變數都不應該持有乙個指向具體類的指標或者引用。
2、任何類都不應該從具體類派生。
3、任何方法都不應該覆寫它的任何基類中的已經實現的方法。
核心思想：
不應該強迫客戶程式依賴他們不需要使用的方法。
介面分離原則的意思就是：乙個介面不需要提供太多的行為，乙個介面應該只提供一種對外的功能，不應該把所有的操作都封裝到乙個介面當中.
分離介面的兩種實現方法：
1.使用委託分離介面。（separation through delegation）
2.使用多重繼承分離介面。（separation through multiple inheritance）
說明：物件與物件之間應該使用盡可能少的方法來關聯，避免千絲萬縷的關係。
如何實現迪公尺特法則？
迪公尺特法則的主要用意是控制資訊的過載，在將其運用到系統設計中應注意以下幾點：
1) 在類的劃分上，應當建立有弱耦合的類。類之間的耦合越弱，就越有利於復用。
2) 在類的結構設計上，每乙個類都應當盡量降低成員的訪問許可權。乙個類不應當public自己的屬性，而應當提供取值和賦值的方法讓外界間接訪問自己的屬性。
3) 在類的設計上，只要有可能，乙個類應當設計成不變類。
4) 在對其它物件的引用上，乙個類對其它物件的引用應該降到最低。
核心思想：對擴充套件開放，對修改關閉。
優點：按照ocp原則設計出來的系統，降低了程式各部分之間的耦合性，其適應性、靈活性、穩定性都比較好。當已有軟體系統需要增加新的功能時，不需要對作為系統基礎的抽象層進行修改，只需要在原有基礎上附加新的模組就能實現所需要新增的功能。增加的新模組對原有的模組完全沒有影響或影響很小，這樣就無須為原有模組進行重新測試。
如何實現「開-閉」原則？
在物件導向設計中，不允許更改的是系統的抽象層，而允許擴充套件的是系統的實現層。換言之，定義乙個一勞永逸的抽象設計層，允許盡可能多的行為在實現層被實現。
解決問題關鍵在於抽象化，抽象化是物件導向設計的第乙個核心本質。
對乙個事物抽象化，實質上是在概括歸納總結它的本質。抽象讓我們抓住最最重要的東西，從更高一層去思考。這降低了思考的複雜度，我們不用同時考慮那麼多的東西。換言之，我們封裝了事物的本質，看不到任何細節。
在物件導向程式設計中，通過抽象類及介面，規定了具體類的特徵作為抽象層，相對穩定，不需更改，從而滿足「對修改關閉」；而從抽象類匯出的具體類可以改變系統的行為，從而滿足「對擴充套件開放」。
對實體進行擴充套件時，不必改動軟體的源**或者二進位制**。關鍵在於抽象。
核心思想：
盡量使用物件組合，而不是繼承來達到復用的目的。該原則就是在乙個新的物件裡面使用一些已有的物件，
使之成為新物件的一部分：新的物件通過向這些物件的委派達到復用已有功能的目的。
復用的種類：
1.繼承
2.合成聚合
注：在復用時應優先考慮使用合成聚合而不是繼承
只有當以下的條件全部被滿足時，才應當使用繼承關係。
1. 子類是超類的乙個特殊種類，而不是超類的乙個角色，也就是區分「has-a」和「is-a」.只有「is-a」關係才符合繼承關係，「has-a」關係應當使用聚合來描述。
2 .永遠不會出現需要將子類換成另外乙個類的子類的情況。如果不能肯定將來是否會變成另外乙個子類的話，就不要使用繼承。
3 .子類具有擴充套件超類的責任，而不是具有置換掉或登出掉超類的責任。如果乙個子類需要大量的置換掉超類的行為，那麼這個類就不應該是這個超類的子類。
錯誤的使用繼承而不是合成/聚合的乙個常見原因是錯誤地把「has-a」當成了「is-a」.」is-a」代表乙個類是另外乙個類的一種；而「has-a」代表乙個類是另外乙個類的乙個角色，而不是另外乙個類的特殊種類。
核心：1.在任何父類出現的地方都可以用他的子類來替代（子類應當可以替換父類並出現在父類能夠出現的任何地方）子類必須完全實現父類的方法。
在類中呼叫其他類是務必要使用父類或介面，如果不能使用父類或介面，則說明類的設計已經違背了lsp原則。
2.子類可以有自己的個性。子類當然可以有自己的行為和外觀了，也就是方法和屬性
3.覆蓋或實現父類的方法時輸入引數可以被放大。即子類可以過載父類的方法，但輸入引數應比父類方法中的大，這樣在子類代替父類的時候，呼叫的仍然是父類的方法。即以子類中方法的前置條件必須與超類中被覆蓋的方法的前置條件相同或者更寬鬆。
4.覆蓋或實現父類的方法時輸出結果可以被縮小。
七大設計原則
開閉原則 定義 乙個軟體實體如類 模組和函式應該對擴充套件開放 對修改關閉 用抽象構建框架，用實現擴充套件細節 優點 提高軟體系統的可復用性及可維護性 依賴倒置原則 定義 高層模組不應該依賴低層模組，二者都應該依賴其抽象 抽象不應該依賴細節，細節應該依賴抽象 針對介面程式設計，不要針對實現程式設計 ...
七大設計原則
開閉原則 open closed principle,ocp 是指乙個軟體實體如類 模組和函式應該對擴充套件開放，對修改關閉。強調的是用抽象構建框架，用實現擴充套件細節。可以提高軟體系統的可復用性及可維護性。開閉原則即是面向介面程式設計 開閉原則的實現方法 為了滿足開閉原則的對修改關閉原則以及擴充套...
設計模式 七大設計原則
定義 應該有且只有乙個原因，引起類的變更 組合是一種強耦合關係，你我都有共同的生命週期，這種強耦合關係，不如直接使用介面實現 建議 介面一定要做到單一原則，類的設計盡量做到只有乙個原因引起變更 定義 所有使用父類的地方，必須能夠透明的使用其子類，反之不行 子類不能完整地實現父類的方法，或者父類的某些...