OO設計原則總結

       設計原則是基本的工具，應用這些規則可以使代碼更加靈活、更容易維護，更容易擴展。基本原則：封裝變化Encapsulate what varies. 面向接口變成而不是實現 Code to an interface rather than to an implementation. 優先使用組合而非繼承 Favor Composition Over Inheritan

 

什麼是設計原則？ 

設計原則是基本的工具，應用這些規則可使你的代碼更加靈活、更容易維護，更容易擴展。

基本原則

• 封裝變化Encapsulate what varies.
• 面向接口變成而不是實現 Code to an interface rather than to an implementation.
• 優先使用組合而非繼承 Favor Composition Over Inheritance

SRP: The single responsibility principle 單一職責

系統中的每個對象都應該只有一個單獨的職責，而全部對象所關注的就是自身職責的完成。

Every object in your system should have a single responsibility ,and all the object s services should  be focused on carrying out that single responsibility .

1. 每個職責都是一個設計的變因，需求變化的時候，需求變化反映爲類職責的變化。當你係統裏面的對象都只有一個變化的緣由的時候，你就已經很好的遵循了SRP原則。
2. 若是一個類承擔的職責過多，就等於把這些職責耦合在了一塊兒。一個職責的變化就可能削弱或者抑制這個類其它職責的能力。這種設計會致使脆弱的設計。當變化發生的時候，設計會遭到意想不到的破壞。
3. SRP 讓這個系統更容易管理維護，由於不是全部的問題都攪在一塊兒。
4. 內聚Cohesion 實際上是SRP原則的另一個名字.你寫了高內聚的軟件其實就是說你很好的應用了SRP原則。
5. 怎麼判斷一個職責是否是一個對象的呢？你試着讓這個對象本身來完成這個職責，好比：「書本身閱讀內容」，閱讀的職責顯然不是書本身的。
6. 僅當變化發生時，變化的軸線才具備實際的意義，若是沒有徵兆，那麼應用SRP或者任何其它的原則都是不明智的。

DRY : Don't repeat yourself Principle

經過抽取公共部分放置在一個地方避免代碼重複.

Avoid duplicate code by abstracting out things that are common and placing those thing in a single location .

1. DRY 很簡單，但倒是確保咱們代碼容易維護和複用的關鍵。
2. 你盡力避免重複代碼候實際上在作一件什麼事情呢？是在確保每個需求和功能在你的系統中只實現一次，不然就存在浪費！系統用例不存在交集，因此咱們的代碼更不該該重複，從這個角度看DRY可就不僅是在說代碼了。
3. DRY 關注的是系統內的信息和行爲都放在一個單一的，明顯的位置。就像你能夠猜到正則表達式在.net中的位置同樣，由於合理因此能夠猜到。
4. DRY 原則：如何對系統職能進行良好的分割！職責清晰的界限必定程度上保證了代碼的單一性。
   

OCP : Open-Close Principle開閉原則

類應該對修改關閉，對擴展打開；

Classes should be open for extension ,and closed  for modification .

1. OCP 關注的是靈活性，改動是經過增長代碼進行的，而不是改動現有的代碼；
2. OCP的應用限定在可能會發生的變化上，經過建立抽象來隔離之後發生的同類變化
3. OCP原則傳遞出來這樣一個思想：一旦你寫出來了能夠工做的代碼，就要努力保證這段代碼一直能夠工做。這能夠說是一個底線。稍微提升一點要求,一旦咱們的代碼質量到了一個水平，咱們要盡最大努力保證代碼質量不回退。這樣的要求使咱們面對一個問題的時候不會使用湊活的方法來解決，或者說是聽任自流的方式來解決一個問題；好比代碼添加了無數對特定數據的處理，特化的代碼愈來愈多，代碼意圖開始含混不清，開始退化。
4. OCP 背後的機制：封裝和抽象；封閉是創建在抽象基礎上的，使用抽象得到顯示的封閉；繼承是OCP最簡單的例子。除了子類化和方法重載咱們還有一些更優雅的方法來實現好比組合；

怎樣在不改變源代碼（關閉修改）的狀況下更改它的行爲呢？答案就是抽象，OCP背後的機制就是抽象和多態

5. 沒有一個能夠適應全部狀況的貼切的模型！必定會有變化，不可能徹底封閉.對程序中的每個部分都肆意的抽象不是一個好主意，正確的作法是開發人員僅僅對頻繁變化的部分作出抽象。拒毫不成熟的抽象和抽象自己同樣重要。
6. OCP是OOD不少說法的核心，若是這個原則有效應用，咱們就能夠獲更強的可維護性 可重用 靈活性 健壯性 LSP是OCP成爲可能的主要原則之一

LSP: The Liskov substitution principle

子類必須可以替換基類。

Subtypes must be substitutable  for their base types.

1. LSP關注的是怎樣良好的使用繼承.
2. 必需要清楚是使用一個Method仍是要擴展它，可是絕對不是改變它。
3. LSP清晰的指出，OOD的IS-A關係是就行爲方式而言，行爲方式是能夠進行合理假設的，是客戶程序所依賴的。
4. LSP讓咱們得出一個重要的結論：一個模型若是孤立的看，並不具備真正意義的有效性。模型的有效性只能經過它的客戶程序來表現。必須根據設計的使用者作出的合理假設來審視它。而假設是難以預測的，直到設計臭味出現的時候才處理它們。
5. 對於LSP的違反也潛在的違反了OCP

DIP：依賴倒置原則

高層模塊不該該依賴於底層模塊 兩者都應該依賴於抽象

抽象不該該依賴於細節 細節應該依賴於抽象

1. 什麼是高層模塊？高層模塊包含了應用程序中重要的策略選擇和業務模型。這些高層模塊使其所在的應用程序區別於其它。
2. 若是高層模塊依賴於底層模塊，那麼在不一樣的上下文中重用高層模塊就會變得十分困難。然而，若是高層模塊獨立於底層模塊，那麼高層模塊就能夠很是容易的被重用。該原則就是框架設計的核心原則。
3. 這裏的倒置不只僅是依賴關係的倒置也是接口全部權的倒置。應用了DIP咱們會發現每每是客戶擁有抽象的接口，而服務者從這些抽象接口派生。
4. 這就是著名的Hollywood原則:"Don't call us we'll call you."底層模塊實現了在高層模塊聲明並被高層模塊調用的接口。
5. 經過倒置咱們建立了更靈活 更持久更容易改變的結構
6. DIP的簡單的啓發規則：依賴於抽象；這是一個簡單的陳述，該規則建議不該該依賴於具體的類，也就是說程序彙總全部的依賴都應該種植於抽象類或者接口。
7. 若是一個類很穩定，那麼依賴於它不會形成傷害。然而咱們本身的具體類大可能是不穩定的，經過把他們隱藏在抽象接口後面能夠隔離不穩定性。
8. 依賴倒置能夠應用於任何存在一個類向另外一個類發送消息的地方
9. 依賴倒置原則是實現許多面向對象技術多宣稱的好處的基本底層機制，是面向對象的標誌所在。

ISP:接口隔離原則

不該該強迫客戶程序依賴它們不須要的使用的方法。

 

1. 接口不是高內聚的，一個接口能夠分紅N組方法，那麼這個接口就須要使用ISP處理一下。
2. 接口的劃分是由使用它的客戶程序決定的，客戶程序是分離的接口也應該是分離的。
3. 一個接口中包含太多行爲時候，致使它們的客戶程序之間產生不正常的依賴關係，咱們要作的就是分離接口，實現解耦。
4. 應用了ISP以後，客戶程序看到的是多個內聚的接口。