**開閉原則**(Open Closed Principle) **定義**：軟件實體應該對擴展開放，對修改關閉。 **由來**：一些軟件生命周期很長，必然面臨維護升級等變化。而新添加的代碼很容易對舊有的代碼造成影響，甚至給舊有的代碼帶來Bug。 **解決**：當軟件代碼需要進行變動時，盡量以添加新的代碼來完成，而不去修改原有的代碼。也即通過擴展來完成所需要的功能的添加。 **里氏替換原則**(**Liskov Substitution Principle**)** **定義**：繼承必須確保父類所擁有的性質在子類中仍然成立。 **由來**：通過子類來完成父類的任務，可能會產生問題。 **解決**：子類可以實現父類的抽象方法，但是不去Override父類的非抽象方法。這也算是某種意義上的開閉原則吧，盡量不要去影響舊有的代碼，通過擴展(取新名字,而不是Override)來完成新功能。 依賴倒置原則(Dependence Inversion Principle) **定義**：高層模塊不依賴于底層模塊，兩者都應該依賴于抽象，抽象不依賴于細節，細節依賴于抽象。 **由來**：表示層、業務邏輯層以及數據訪問層之間如果分得不太清楚，各模塊之間交叉調用，就會帶來很強的耦合性，往往會牽一發而動全身，改動一個地方，很多地方都會受到影響，增加出錯的風險。 **解決**：主要是通過面對接口編程，將實現細節與業務邏輯分開，它們都是通過抽象的接口來完成交互的。業務邏輯只和抽象的接口打交到，而不必關注具體的實現過程。同樣實現過程也不必關注業務，它只需要關注接口即抽象即可。 **接口隔離原則**(Interface Segregation Principle)** **定義**：客戶端不應該依賴它不需要的接口；一個類對另一個類的依賴應建立在最小接口上。 **由來**：一個接口里完成了很多工作，但是當個功能只需要調用接口里的一小部分功能的時候，如果調用這個接口，就會做一些不必要的工作，甚至可能產生問題。 **解決**：一個接口盡量完成比較單一的任務，這樣兩個類交互時，產生的影響才會在控制范圍內。 **合成**/**聚合復用原則**(Composite/Aggregate Reuse Principle)** **定義**：能夠使用合成/聚合的，不要使用繼承。合成是指局部與整體的關系；聚合則是包含的關系。 **由來**：繼承關系是在編譯時就確定了，如果想在運行時改變父類與子類的關系就不行了；另外父類改變了一定會影響到子類。繼承的關系限制了更靈活地復用代碼。 **解決**：通過使用合成/聚合來替代繼承關系，達到更靈活地修改代碼。 **迪米特法則**(Law Of Demeter)** **定義**：也稱最少知道原則(Least Knowledge Principle),只和你最直接的類(成員變量、方法參數、方法返回值中的類)溝通，盡可能少地與其他實體發生交互。 **由來**：想降低類之間的耦合關系，相互之間盡量減少依賴關系。 **解決**：與越少的類相互越好，盡量做到低耦合高內聚。盡量做到模塊化。 P.S.???經常被提到的原則還有單一職責原則(Single Responsibility Principle)，一個類只應該有一個引起它變化的原因，也即一個類只負責一件事。像流水線作業一樣，一位員工只負責自己的那一部分，完了就交給其他員工。 P.S.??設計模式的這幾大原則，是我們設計模式的一個根本。每一個設計模式都是為了更好的完成這些設計模式的原則而總結設計出來的。設計模式的原則是基本功，而23個設計模式則是對基本功的應用。當23個設計模式能夠融會貫通的時候，就可以不用固定于那23個設計模式了，而是根據這些設計模式的原則來自由設計代碼。