C#中面向對象設計七個原則是什么

今天就跟大家聊聊有關C#中面向對象設計七個原則是什么，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結了以下內容，希望大家根據這篇文章可以有所收獲。

一：單一職責原則(Single Responsibility Principle, SRP)

   1、定義：一個對象應該只包含單一的職責，并且該職責被完整地封裝在一個類中

　　   或者：就一個類而言，應該僅有一個引起它變化的原因。

  2、分析：一個類（或者大到模塊，小到方法）承擔的職責越多，它被復用的可能性越小，而且如果一個類承擔的職責過多，就相當于將這些職責耦合在一起，當其中一個職責變化時，可能會影響其他職責的運作。 類的職責主要包括兩個方面：數據職責和行為職責，數據職責通過其屬性來體現，而行為職責通過其方法來體現。 單一職責原則是實現高內聚、低耦合的指導方針，在很多代碼重構手法中都能找到它的存在，它是最簡單但又最難運用的原則，需要設計人員發現類的不同職責并將其分離，而發現類的多重職責需要設計人員具有較強的分析設計能力和相關重構經驗。

  3、實例：

實例說明 某基于Java的C/S系統的“登錄功能”通過如下登錄類(Login)實現：
現使用單一職責原則對其進行重構。

二：開閉原則(Open-Closed Principle, OCP)

    1、定義：一個軟件實體應當對擴展開放，對修改關閉。也就是說在設計一個模塊的時候，應當使這個模塊可以在不被修改的前提下被擴展，即實現在不修改源代碼的情況下改變這個模塊的行為。  

  2、分析：開閉原則由Bertrand Meyer于1988年提出，它是面向對象設計中最重要的原則之一。在開閉原則的定義中，軟件實體可以指一個軟件模塊、一個由多個類組成的局部結構或一個獨立的類。抽象化是開閉原則的關鍵。 開閉原則還可以通過一個更加具體的“對可變性封裝原則”來描述，對可變性封裝原則(Principle of Encapsulation of Variation, EVP)要求找到系統的可變因素并將其封裝起來。

三：里氏代換原則(Liskov Substitution Principle, LSP)      

1、定義：如果對每一個類型為S的對象o1，都有類型為T的對象o2，使得以T定義的所有程序P在所有的對象o1都代換成o2時，程序P的行為沒有變化，那么類型S是類型T的子類型

　　或者：所有引用基類（父類）的地方必須能透明地使用其子類的對象。

2、分析：里氏代換原則由2008年圖靈獎得主、美國第一位計算機科學女博士、麻省理工學院教授Barbara Liskov和卡內基.梅隆大學Jeannette Wing教授于1994年提出。

里氏代換原則可以通俗表述為：在軟件中如果能夠使用基類對象，那么一定能夠使用其子類對象。把基類都替換成它的子類，程序將不會產生任何錯誤和異常，反過來則不成立，如果一個軟件實體使用的是一個子類的話，那么它不一定能夠使用基類。里氏代換原則是實現開閉原則的重要方式之一，由于使用基類對象的地方都可以使用子類對象，因此在程序中盡量使用基類類型來對對象進行定義，而在運行時再確定其子類類型，用子類對象來替換父類對象。

四：依賴倒轉原則(Dependence Inversion Principle, DIP)    

1、定義：高層模塊不應該依賴低層模塊，它們都應該依賴抽象。抽象不應該依賴于細節，細節應該依賴于抽象

　　或者：要針對接口編程，不要針對實現編程。（Program to an interface, not an implementation.）  

2、分析：依賴倒轉原則是Robert C. Martin在1996年為《C++ Reporter》所寫的專欄Engineering Notebook的第三篇，后來加入到他在2002年出版的經典著作《Agile Software Development, Principles, Patterns, and Practices》中。  

    簡單來說，依賴倒轉原則就是指：代碼要依賴于抽象的類，而不要依賴于具體的類；要針對接口或抽象類編程，而不是針對具體類編程。 實現開閉原則的關鍵是抽象化，并且從抽象化導出具體化實現，如果說開閉原則是面向對象設計的目標的話，那么依賴倒轉原則就是面向對象設計的主要手段。

  依賴倒轉原則的常用實現方式之一是在代碼中使用抽象類，而將具體類放在配置文件中。

類之間的耦合

零耦合關系

具體耦合關系

抽象耦合關系

依賴倒轉原則要求客戶端依賴于抽象耦合，以抽象方式耦合是依賴倒轉原則的關鍵。

依賴注入

構造注入(Constructor Injection)：通過構造函數注入實例變量。

設值注入(Setter Injection)：通過Setter方法注入實例變量。

接口注入(Interface Injection)：通過接口方法注入實例變量。

五：接口隔離原則(Interface Segregation Principle, ISP)

  1、定義：客戶端不應該依賴那些它不需要的接口   注意，在該定義中的接口指的是所定義的方法。

　　 或者：一旦一個接口太大，則需要將它分割成一些更細小的接口，使用該接口的客戶端僅需知道與之相關的方法即可。

  2、分析：接口隔離原則是指使用多個專門的接口，而不使用單一的總接口。每一個接口應該承擔一種相對獨立的角色，不多不少，不干不該干的事，該干的事都要干。

　(1) 一個接口就只代表一個角色，每個角色都有它特定的一個接口，此時這個原則可以叫做“角色隔離原則”。

  (2) 接口僅僅提供客戶端需要的行為，即所需的方法，客戶端不需要的行為則隱藏起來，應當為客戶端提供盡可能小的單獨的接口，而不要提供大的總接口。

       使用接口隔離原則拆分接口時，首先必須滿足單一職責原則，將一組相關的操作定義在一個接口中，且在滿足高內聚的前提下，接口中的方法越少越好。 可以在進行系統設計時采用定制服務的方式，即為不同的客戶端提供寬窄不同的接口，只提供用戶需要的行為，而隱藏用戶不需要的行為。

六：合成復用原則(Composite Reuse Principle, CRP)又稱為組合/聚合復用原則(Composition/ Aggregate Reuse Principle, CARP)

    1、定義：盡量使用對象組合，而不是繼承來達到復用的目的。（Favor composition of objects over inheritance as a reuse mechanism.）

    2、分析：合成復用原則就是指在一個新的對象里通過關聯關系（包括組合關系和聚合關系）來使用一些已有的對象，使之成為新對象的一部分；新對象通過委派調用已有對象的方法達到復用其已有功能的目的。簡言之：要盡量使用組合/聚合關系，少用繼承。

在面向對象設計中，可以通過兩種基本方法在不同的環境中復用已有的設計和實現，即通過組合/聚合關系或通過繼承。
繼承復用：實現簡單，易于擴展。破壞系統的封裝性；從基類繼承而來的實現是靜態的，不可能在運行時發生改變，沒有足夠的靈活性；只能在有限的環境中使用。（“白箱”復用 ）

組合/聚合復用：耦合度相對較低，選擇性地調用成員對象的操作；可以在運行時動態進行。（“黑箱”復用 ）
組合/聚合可以使系統更加靈活，類與類之間的耦合度降低，一個類的變化對其他類造成的影響相對較少，因此一般首選使用組合/聚合來實現復用；其次才考慮繼承，在使用繼承時，需要嚴格遵循里氏代換原則，有效使用繼承會有助于對問題的理解，降低復雜度，而濫用繼承反而會增加系統構建和維護的難度以及系統的復雜度，因此需要慎重使用繼承復用。

七：迪米特法則(Law of Demeter, LoD)又稱為最少知識原則(Least Knowledge Principle, LKP)

1、定義：

(1) 不要和“陌生人”說話。英文定義為：Don't talk to strangers.

(2) 只與你的直接朋友通信。英文定義為：Talk only to your immediate friends.

(3) 每一個軟件單位對其他的單位都只有最少的知識，而且局限于那些與本單位密切相關的軟件單位。英文定義為：Each unit should have only limited knowledge about other units: only units "closely" related to the current unit.  

 2、分析：迪米特法則來自于1987年秋美國東北大學(Northeastern University)一個名為“Demeter”的研究項目。簡單地說，迪米特法則就是指一個軟件實體應當盡可能少的與其他實體發生相互作用。這樣，當一個模塊修改時，就會盡量少的影響其他的模塊，擴展會相對容易，這是對軟件實體之間通信的限制，它要求限制軟件實體之間通信的寬度和深度。

看完上述內容，你們對C#中面向對象設計七個原則是什么有進一步的了解嗎？如果還想了解更多知識或者相關內容，請關注億速云行業資訊頻道，感謝大家的支持。