C#物件導向的基本原則

什麼是物件導向的基本原則？
設計原則是基本的工具，應用這些規則可以使你的代碼更加靈活、更容易維護，更容易擴充。

C#物件導向的基本原則

一、面向介面編成而不是實現 [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 .]

       每一個職責都是一個設計的變因，需求變化的時候，需求變化反映為類職責的變化。當你系統裡面的對象都只有一個變化的原因的時候，你就已經很好的遵循了SRP原則。 如果一個類承擔的職責過多，就等於把這些職責耦合在了一起。一個職責的變化就可能削弱或者抑制這個類其它職責的能力。這種設計會導致脆弱的設計。當變化發生的時候，設計會遭到意想不到的破壞。SRP 讓這個系統更容易管理維護，因為不是所有的問題都攪在一起。
      內聚[Cohesion[ 其實是SRP原則的另外一個名字.你寫了高內聚的軟體其實就是說你很好的應用了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 .]
      DRY 很簡單，但卻是確保我們代碼容易維護和複用的關鍵。你儘力避免重複代碼實際上是在確保每一個需求和功能在你的系統中只實現一次，否則就存在浪費！系統用例不存在交集，所以我們的代碼更不應該重複，從這個角度看DRY可就不只是在說代碼了。
      DRY 關注的是系統內的資訊和行為都放在一個單一的，明顯的位置。就像你可以猜到Regex在.net中的位置一樣，因為合理所以可以猜到。
      DRY 原則：如何對系統職能進行良好的分割！職責清晰的界限一定程度上保證了代碼的單一性。

五、OCP : Open-Close Principle 開放閉合原則
            類應該對修改關閉，對擴充開啟；[Classes should be open for extension ,and closed  for modification .]
      OCP 關注的是靈活性，改動是通過增加代碼進行的，而不是改動現有的代碼； 
      OCP的應用限定在可能會發生的變化上，通過建立抽象來隔離以後可能發生的同類變化
      OCP原則傳遞出來這樣一個思想：一旦你寫出來了可以工作的代碼，就要努力保證這段代碼一直可以工作。這可以說是一個底線。稍微提高一點要求,一旦我們的代碼品質到了一個水平，我們要盡最大努力保證代碼品質不回退。這樣的要求使我們面對一個問題的時候不會使用湊活的方法來解決，或者說是放任自流的方式來解決一個問題；比如代碼添加了無數對特定資料的處理，特化的代碼越來越多，代碼意圖開始含混不清，開始退化。
     OCP 背後的機制：封裝和抽象；封閉是建立在抽象基礎上的，使用抽象獲得顯示的封閉；繼承是OCP最簡單的例子。除了子類化和方法重載我們還有一些更優雅的方法來實現比如組合； 怎樣在不改變原始碼（關閉修改）的情況下更改它的行為呢？答案就是抽象，OCP背後的機制就是抽象和多態.沒有一個可以適應所有情況的貼切的模型！一定會有變化，不可能完全封閉.對程式中的每一個部分都肆意的抽象不是一個好主意，正確的做法是開發人員僅僅對頻繁變化的部分做出抽象。拒絕不成熟的抽象和抽象本身一樣重要。    OCP是OOD很多說法的核心，如果這個原則有效應用，我們就可以獲更強的可維護性 可重用 靈活性 健壯性 LSP是OCP成為可能的主要原則之一
六、LSP: The Liskov substitution principle  裡氏替換原則
子類必須能夠替換基類。[Subtypes must be substitutable  for their base types.]
      LSP關注的是怎樣良好的使用繼承.  必須要清楚是使用一個Method還是要擴充它，但是絕對不是改變它。
      LSP清晰的指出，OOD的IS-A關係是就行為方式而言，行為方式是可以進行合理假設的，是客戶程式所依賴的。
      LSP讓我們得出一個重要的結論：一個模型如果孤立的看，並不具有真正意義的有效性。模型的有效性只能通過它的客戶程式來表現。必鬚根據設計的使用者做出的   合理假設來審視它。而假設是難以預測的，直到設計臭味出現的時候才處理它們。
      對於LSP的違反也潛在的違反了OCP 。
七、DIP：依賴倒置原則
      高層模組不應該依賴於底層模組 二者都應該依賴於抽象，抽象不應該依賴於細節 細節應該依賴於抽象。
      什麼是高層模組？高層模組包含了應用程式中重要的策略選擇和業務模型。這些高層模組使其所在的應用程式區別於其它。 如果高層模組依賴於底層模組，那麼在不同的上下文中重用高層模組就會變得十分困難。然而，如果高層模組獨立於底層模組，那麼高層模組就可以非常容易的被重用。該原則就是架構設計的核心原則。這裡的倒置不僅僅是依賴關係的倒置也是介面所有權的倒置。應用了DIP我們會發現往往是客戶擁有抽象的介面，而服務者從這些抽象介面派生。這就是著名的Hollywood原則:"Don't call us we'll call you."底層模組實現了在高層模組聲明並被高層模組調用的介面。通過倒置我們建立了更靈活 更持久更容易改變的結構。
        DIP的簡單的啟發規則：依賴於抽象；這是一個簡單的陳述，該規則建議不應該依賴於具體的類，也就是說程式匯總所有的依賴都應該種植於抽象類別或者介面。如果一個類很穩定，那麼依賴於它不會造成傷害。然而我們自己的具體類大多是不穩定的，通過把他們隱藏在抽象介面後面可以隔離不穩定性。依賴倒置可以應用於任何存在一個類向另一個類發送訊息的地方，依賴倒置原則是實現許多物件導向技術多宣稱的好處的基本底層機制，是物件導向的標誌所在。
八、ISP:介面隔離原則
     不應該強迫客戶程式依賴它們不需要的使用的方法。
     介面不是高內聚的，一個介面可以分成N組方法，那麼這個介面就需要使用ISP處理一下。
     介面的劃分是由使用它的客戶程式決定的，客戶程式是分離的介面也應該是分離的。
      一個介面中包含太多行為時候，導致它們的客戶程式之間產生不正常的依賴關係，我們要做的就是分離介面，實現解耦。
     應用了ISP之後，客戶程式看到的是多個內聚的介面。