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”的研究項目。簡單地說，迪米特法則就是指一個軟體實體應當儘可能少的與其他實體發生相互作用。這樣，當一個模組修改時，就會盡量少的影響其他的模組，擴充會相對容易，這是對軟體實體之間通訊的限制，它要求限制軟體實體之間通訊的寬度和深度。