C#面向物件設計的七大原則
本文我們要談的七大原則，即：單一職責，里氏替換，迪米特法則，依賴倒轉，介面隔離，合成/聚合原則，開放-封閉 。
1. 開閉原則(Open-Closed Principle, OCP)
定義：軟體實體應當對擴充套件開放，對修改關閉。這句話說得有點專業，更通俗一點講，也就是：軟體系統中包含的各種元件，例如模組（Modules）、類（Classes）以及功能（Functions）等等，應該在不修改現有程式碼的基礎上，去擴充套件新功能。開閉原則中原有“開”，是指對於元件功能的擴充套件是開放的，是允許對其進行功能擴充套件的；開閉原則中“閉”，是指對於程式碼的修改是封閉的，即不應該修改原有的程式碼。
問題由來：
解決方法：當軟體需要變化時，儘量通過擴充套件軟體實體的行為來實現變化，而不是通過修改已有的程式碼來實現變化。
小結：開閉原則具有理想主義的色彩，說的很抽象，它是面向物件設計的終極目標。其他幾條原則，則可以看做是開閉原則的實現。我們要用抽象構建框架，用實現擴充套件細節。
2. 單一職責原則（Single Responsibility Principle）
定義：一個類，只有一個引起它變化的原因。即：應該只有一個職責。
每一個職責都是變化的一個軸線，如果一個類有一個以上的職責，這些職責就耦合在了一起。這會導致脆弱的設計。當一個職責發生變化時，可能會影響其它的職責。另外，多個職責耦合在一起，會影響複用性。例如：要實現邏輯和介面的分離。需要說明的一點是單一職責原則不只是面向物件程式設計思想所特有的，只要是模組化的程式設計，都需要遵循這一重要原則。
問題由來：類T負責兩個不同的職責：職責P1，職責P2。當由於職責P1需求發生改變而需要修改類T時，有可能會導致原本執行正常的職責P2功能發生故障。
解決方法：分別建立兩個類T1、T2，使T1完成職責P1功能，T2完成職責P2功能。這樣，當修改類T1時，不會使職責P2發生故障風險；同理，當修改T2時，也不會使職責P1發生故障風險。
3. 里氏替換原則（Liskov Substitution Principle）
定義：子型別必須能夠替換掉它們的父型別。注意這裡的能夠兩字。有人也戲稱老鼠的兒子會打洞原則。
問題由來：有一功能P1，由類A完成。現需要將功能P1進行擴充套件，擴充套件後的功能為P，其中P由原有功能P1與新功能P2組成。新功能P由類A的子類B來完成，則子類B在完成新功能P2的同時，有可能會導致原有功能P1發生故障。
解決方法：類B繼承類A時，除新增新的方法完成新增功能P2外，儘量不要重寫父類A的方法，也儘量不要過載父類A的方法
小結：所有引用父類的地方必須能透明地使用其子類的物件。子類可以擴充套件父類的功能，但不能改變父類原有的功能，即：子類可以實現父類的抽象方法，子類也中可以增加自己特有的方法，但不能覆蓋父類的非抽象方法。當子類的方法過載父類的方法時，方法的前置條件（即方法的形參）要比父類方法的輸入引數更寬鬆。當子類的方法實現父類的抽象方法時，方法的後置條件（即方法的返回值）要比父類更嚴格。
4. 迪米特法則（Law Of Demeter）
定義：迪米特法則又叫最少知道原則，即：一個物件應該對其他物件保持最少的瞭解。如果兩個類不必彼此直接通訊，那麼這兩個類就不應當發生直接的相互作用。如果其中一個類需要呼叫另一個類的某一個方法的話，可以通過第三者轉發這個呼叫。簡單定義為只與直接的朋友通訊。首先來解釋一下什麼是直接的朋友：每個物件都會與其他物件有耦合關係，只要兩個物件之間有耦合關係，我們就說這兩個物件之間是朋友關係。耦合的方式很多，依賴、關聯、組合、聚合等。其中，我們稱出現成員變數、方法引數、方法返回值中的類為直接的朋友，而出現在區域性變數中的類則不是直接的朋友。也就是說，陌生的類最好不要作為區域性變數的形式出現在類的內部。
問題由來：類與類之間的關係越密切，耦合度越大，當一個類發生改變時，對另一個類的影響也越大。
最早是在1987年由美國Northeastern University的Ian Holland提出。通俗的來講，就是一個類對自己依賴的類知道的越少越好。也就是說，對於被依賴的類來說，無論邏輯多麼複雜，都儘量地的將邏輯封裝在類的內部，對外除了提供的public方法，不對外洩漏任何資訊。迪米特法則還有一個更簡單的定義：只與直接的朋友通訊。
解決方法：儘量降低類與類之間的耦合。 自從我們接觸程式設計開始，就知道了軟體程式設計的總的原則：低耦合，高內聚。無論是面向過程程式設計還是面向物件程式設計，只有使各個模組之間的耦合儘量的低，才能提高程式碼的複用率。
迪米特法則的初衷是降低類之間的耦合，由於每個類都減少了不必要的依賴，因此的確可以降低耦合關係。但是凡事都有度，雖然可以避免與非直接的類通訊，但是要通訊，必然會通過一個“中介”來發生聯絡。故過分的使用迪米特原則，會產生大量這樣的中介和傳遞類，導致系統複雜度變大。所以在採用迪米特法則時要反覆權衡，既做到結構清晰，又要高內聚低耦合。
5. 依賴倒置原則（Dependence Inversion Principle）
定義：高層模組不應該依賴低層模組，二者都應該依賴其抽象；抽象不應該依賴細節；細節應該依賴抽象。中心思想是面向介面程式設計
問題由來：類A直接依賴類B，假如要將類A改為依賴類C，則必須通過修改類A的程式碼來達成。這種場景下，類A一般是高層模組，負責複雜的業務邏輯；類B和類C是低層模組，負責基本的原子操作；假如修改類A，會給程式帶來不必要的風險。
解決方法：將類A修改為依賴介面I，類B和類C各自實現介面I，類A通過介面I間接與類B或者類C發生聯絡，則會大大降低修改類A的機率。
在實際程式設計中，我們一般需要做到如下3點：
1）. 低層模組儘量都要有抽象類或介面，或者兩者都有。
2）. 變數的宣告型別儘量是抽象類或介面。
3）. 使用繼承時遵循里氏替換原則。
採用依賴倒置原則尤其給多人合作開發帶來了極大的便利，參與協作開發的人越多、專案越龐大，採用依賴導致原則的意義就越重大。
小結：依賴倒置原則就是要我們面向介面程式設計，理解了面向介面程式設計，也就理解了依賴倒置。
6. 介面隔離原則（Interface Segregation Principle）
定義：客戶端不應該依賴它不需要的介面；一個類對另一個類的依賴應該建立在最小的介面上。
問題由來：類A通過介面I依賴類B，類C通過介面I依賴類D，如果介面I對於類A和類B來說不是最小介面，則類B和類D必須去實現他們不需要的方法
解決方法：1、 使用委託分離介面。2、 使用多重繼承分離介面。3.將臃腫的介面I拆分為獨立的幾個介面，類A和類C分別與他們需要的介面建立依賴關係。也就是採用介面隔離原則。
舉例說明：
下面我們來看張圖，一切就一目瞭然了。
這個圖的意思是：類A依賴介面I中的方法1、方法2、方法3，類B是對類A依賴的實現。類C依賴介面I中的方法1、方法4、方法5，類D是對類C依賴的實現。對於類B和類D來說，雖然他們都存在著用不到的方法（也就是圖中紅色字型標記的方法），但由於實現了介面I，所以也必須要實現這些用不到的方法
修改後：
如果介面過於臃腫，只要介面中出現的方法，不管對依賴於它的類有沒有用處，實現類中都必須去實現這些方法，這顯然不是好的設計。如果將這個設計修改為符合介面隔離原則，就必須對介面I進行拆分。在這裡我們將原有的介面I拆分為三個介面
小結：我們在程式碼編寫過程中，運用介面隔離原則，一定要適度，介面設計的過大或過小都不好。對介面進行細化可以提高程式設計靈活性是不掙的事實，但是如果過小，則會造成介面數量過多，使設計複雜化。所以一定要適度。設計介面的時候，只有多花些時間去思考和籌劃，就能準確地實踐這一原則。
7. 合成/聚合原則(Composite/Aggregate Reuse Principle,CARP)
定義：也有人叫做合成複用原則，及儘量使用合成/聚合，儘量不要使用類繼承。換句話說，就是能用合成/聚合的地方，絕不用繼承。
為什麼要儘量使用合成/聚合而不使用類繼承？
1. 物件的繼承關係在編譯時就定義好了，所以無法在執行時改變從父類繼承的子類的實現
2. 子類的實現和它的父類有非常緊密的依賴關係，以至於父類實現中的任何變化必然會導致子類發生變化
3. 當你複用子類的時候，如果繼承下來的實現不適合解決新的問題，則父類必須重寫或者被其它更適合的類所替換，這種依賴關係限制了靈活性，並最終限制了複用性。
總結：這些原則在設計模式中體現的淋淋盡致，設計模式就是實現了這些原則，從而達到了程式碼複用、增強了系統的擴充套件性。所以設計模式被很多人奉為經典。我們可以通過好好的研究設計模式，來慢慢的體會這些設計原則。