C#七種設計原則

在C#中有七種設計原則 分別是

1.開閉原則(Open-Closed Principle, OCP)

2.單一職責原則（Single Responsibility Principle）

3.里氏替換原則（Liskov Substitution Principle）

4.迪米特法則（Law Of Demeter）

5.依賴倒置原則（Dependence Inversion Principle）

6.接口隔離原則（Interface Segregation Principle）

7.合成/聚合原則(Composite/Aggregate Reuse Principle,CARP)

就一一介紹着七種設計原則

1.開閉原則(Open-Closed Principle, OCP)

定義：一個軟件實體如類、模塊和函數應該對擴展開放，對修改關閉。

我的解釋：軟件實體如同你租住的房子通常 你能夠向裏面添加東西 可是卻很難修改這個房間

擴展開放就至關於你向租住的房子裏放置傢俱 充實這個房子的功能

修改關閉就比如是房子的已經存在的物件 道理上你是沒有這個改變他們的能力 實際是你在付出代價以後能夠更改

但絕對的修改關閉是不可能的 就比如如水龍頭 下水管道 燈泡等這些房子存在的基本物件損壞同樣 不可避免的

因此須要提早作好準備避免而在軟件中避免就是建立抽象來隔離之後發生同類的變化。

 

開放-封閉原則，能夠保證之前代碼的正確性，由於沒有修改之前代碼，因此能夠保證開發人員專一於將設計放在新擴展的代碼上。

簡單的用一句經典的話來講：過去的事已成歷史，是不可修改的，由於時光不可倒流，但如今或明天計劃作什麼，是能夠本身決定(即擴展)的。

 

2.單一職責原則（Single Responsibility Principle）

定義：即一個類只負責一項職責，應該僅有一個引發它變化的緣由

我的解釋：你有一個帶茶漏的茶杯(即類)用來喝茶和喝水(即兩種職責) 有一天你想將奶茶倒入這個茶杯

但因爲奶茶有珍珠 茶杯有茶漏 爲了將珍珠也放入茶杯中 你將茶漏取出(改變了茶杯的功能)此時的茶杯就

不能用來喝茶 因此該茶杯的職責也就被改變 爲了不這種改變你準備了茶杯和水杯 喝茶就用茶杯 喝水就用水杯

這就符合單一職責 一個類(杯子)只負責一種職責(喝茶或者喝水)

單一職責的優勢：
1.能夠下降類的複雜度，一個類只負責一項職責，其邏輯確定要比負責多項職責簡單的多；
2.提升類的可讀性，提升系統的可維護性；
3.變動引發的風險下降，變動是必然的，若是單一職責原則遵照的好，當修改一個功能時，能夠顯著下降對其餘功能的影響。
須要說明的一點是單一職責原則不僅是面向對象編程思想所特有的，只要是模塊化的程序設計，都須要遵循這一重要原則。

 

3.里氏替換原則（Liskov Substitution Principle）

定義：子類型必須可以替換掉它們的父類型

我的解釋：若是父類型是鳥 子類型是企鵝 在生物學中企鵝歸屬於鳥 可是企鵝不會飛 在編程的世界中 企鵝就沒法歸屬於鳥

即企鵝不能繼承鳥類  

 

 只有當子類能夠替換掉父類，軟件單位的功能不受影響時，父類才能真正被複用，而子類也能夠在父類的基礎上增長新的行爲，

正是有里氏代換原則，使得繼承複用成爲了可能。正是因爲子類型的可替換性才使得使用父類類型的模塊在無需修改的

狀況下就能夠擴展，否則還談什麼擴展開放，修改關閉呢

里氏替換原則通俗的來說就是：子類能夠擴展父類的功能，但不能改變父類原有的功能。

它包含如下4層含義：
1.子類能夠實現父類的抽象方法，但不能覆蓋父類的非抽象方法。
2.子類中能夠增長本身特有的方法。
3.當子類的方法重載父類的方法時，方法的前置條件（即方法的形參）要比父類方法的輸入參數更寬鬆。
4.當子類的方法實現父類的抽象方法時，方法的後置條件（即方法的返回值）要比父類更嚴格。

 

4.迪米特法則（Law Of Demeter）

定義：迪米特法則又叫最少知道原則，即一個對象應該對其餘對象保持最少的瞭解。

解釋：迪米特法則其根本思想，是強調了類之間的鬆耦合，類之間的耦合越弱,越有利於複用，一個處在弱耦合的類被

修改，不會對有關係的類形成影響，也就是說信息的隱藏促進了軟件的複用。

軟件編程的總的原則：低耦合，高內聚。不管是面向過程編程仍是面向對象編程，只有使各個模塊之間的耦合儘可能的低，

才能提升代碼的複用率。而迪米特法則就是解決低耦合的方法

我的解釋：迪米特法則有個簡單的方法叫作：只與直接的朋友通訊。朋友關係在編程中就是耦合關係，耦合的方式就像現實

世界中交朋友同樣有多種，例如：依賴，關聯，組合，聚合等。其中，咱們稱出現成員變量、方法參數、方法返回值中的類爲直接的朋友

而出如今局部變量中的類則不是直接的朋友。也就是說，陌生的類最好不要做爲局部變量的形式出如今類的內部。

 

5.依賴倒置原則（Dependence Inversion Principle）

定義：高層模塊不該該依賴低層模塊，兩者都應該依賴其抽象；抽象不該該依賴細節；細節應該依賴抽象。中心思想是面向接口編程

在實際編程中，咱們通常須要作到以下3點：

1. 低層模塊儘可能都要有抽象類或接口，或者二者都有。

2. 變量的聲明類型儘可能是抽象類或接口。

3. 使用繼承時遵循里氏替換原則。

依賴倒置原則基於這樣一個事實：相對於細節的多變性，抽象的東西要穩定的多。以抽象爲基礎搭建起來的架構比以細節爲基礎搭建起來

的架構要穩定的多。在java中，抽象指的是接口或者抽象類，細節就是具體的實現類，使用接口或者抽象類的目的是制定好

規範和契約，而不去涉及任何具體的操做，把展示細節的任務交給他們的實現類去完成。

 

6.接口隔離原則（Interface Segregation Principle）

定義：咱們要爲各個類創建專用的接口，而不要試圖去創建一個很龐大的接口供全部依賴它的類去調用

解釋：在程序設計中，依賴幾個專用的接口要比依賴一個綜合的接口更靈活。就比如術業有專攻同樣。

經過分散定義多個接口，能夠預防外來變動的擴散，提升系統的靈活性和可維護性。

採用接口隔離原則對接口進行約束時，要注意如下幾點：
1. 接口儘可能小，可是要有限度。對接口進行細化能夠提升程序設計靈活性是不掙的事實，可是若是太小，則會形成接口數量過多，使設計複雜化。因此必定要適度。
2. 爲依賴接口的類定製服務，只暴露給調用的類它須要的方法，它不須要的方法則隱藏起來。只有專一地爲一個模塊提供定製服務，才能創建最小的依賴關係。
3. 提升內聚，減小對外交互。使接口用最少的方法去完成最多的事情。

 運用接口隔離原則，必定要適度，接口設計的過大或太小都很差。設計接口的時候，只有多花些時間去思考和籌劃，才能準確地實踐這一原則。

 

7.合成/聚合原則(Composite/Aggregate Reuse Principle,CARP)

定義：儘可能的使用合成和聚合，而不是繼承關係達到複用的目的換句話說，就是能用合成/聚合的地方，毫不用繼承。

 

爲何要儘可能使用合成/聚合而不使用類繼承？

1. 對象的繼承關係在編譯時就定義好了，因此沒法在運行時改變從父類繼承的子類的實現

2. 子類的實現和它的父類有很是緊密的依賴關係，以致於父類實現中的任何變化必然會致使子類發生變化

3. 當你複用子類的時候，若是繼承下來的實現不適合解決新的問題，則父類必須重寫或者被其它更適合的類所替換，這種依賴關係限制了靈活性，並最終限制了複用性。

 

以上就是我對七大設計原則的總結，在之後的生活中若是碰見更好的解釋會增添。