Object-Oriented Principle（物件導向原則）

標籤：

物件導向的原則：

• 開閉原則（Open Closed Principle，OCP）
• 裡氏代換原則（Liskov Substitution Principle，LSP）
• 依賴倒轉原則（Dependency Inversion Principle，DIP）
• 介面隔離原則（Interface Segregation Principle，ISP）
• 合成/彙總複用原則（Composite/Aggregate Reuse Principle，CARP）
• 最小知識原則（Principle of Least Knowledge，PLK，也叫迪米特法則）
• 單一職責原則（Single Responsibility Principal， SRP）

　　開閉原則具有理想主義的色彩，它是物件導向設計的終極目標。其他幾條，則可以看做是開閉原則的實現方法。

開閉原則（Open Closed Principle，OCP）：

　　1988年，勃蘭特·梅耶（Bertrand Meyer）在他的著作《物件導向軟體構造（Object Oriented Software Construction）》中提出了開閉原則，它的原文是這樣：“Software entities should be open for extension, but closed for modification”。翻譯過來就是：“軟體實體應當對擴充開放，對修改關閉”。這句話說得略微有點專業，我們把它講得更通俗一點，也就是：軟體系 統中包含的各種組件，例如模組（Modules）、類（Classes）以及功能（Functions）等等，應該在不修改現有代碼的基礎上，引入新功能。開閉原則中“開”，是指對於組件功能的擴充是開放的，是允許對其進行功能擴充的；開閉原則中“閉”，是指對於原有代碼的修改是封閉的，即不應該修改原有的代碼。

裡氏代換原則（Liskov Substitution Principle，LSP）：

　　裡氏代換原則中說，任何基類可以出現的地方，子類一定可以出現。 LSP是繼承複用的基石，只有當衍生類可以替換掉基類，軟體單位的功能不受到影響時，基類才能真正被複用，而衍生類也能夠在基類的基礎上增加新的行為。裡氏代換原則是對“開-閉”原則的補充。實現“開-閉”原則的關鍵步驟就是抽象化。而基類與子類的繼承關係就是抽象化的具體實現，所以裡氏代換原則是對實現抽象化的具體步驟的規範。

依賴倒轉原則（Dependency Inversion Principle，DIP）：

　　所謂依賴倒置原則（Dependence Inversion Principle）就是要依賴於抽象，不要依賴於具體。簡單的說就是要求對抽象進行編程，不要對實現進行編程，這樣就降低了客戶與實現模組間的耦合。

 介面隔離原則（Interface Segregation Principle，ISP）：

　　使用多個專門的介面比使用單一的總介面要好。

　　一個類對另外一個類的依賴性應當是建立在最小的介面上的。

　　一個介面代表一個角色，不應當將不同的角色都交給一個介面。沒有關係的介面合并在一起，形成一個臃腫的大介面，這是對角色和介面的汙染。

　　“不應該強迫客戶依賴於它們不用的方法。介面屬於客戶，不屬於它所在的類階層。”這個說得很明白了，再通俗點說，不要強迫客戶使用它們不用的方法，如果強迫使用者使用它們不使用的方法，那麼這些客戶就會面臨由於這些不使用的方法的改變所帶來的改變。

 合成/彙總複用原則（Composite/Aggregate Reuse Principle，CARP）：

　　合成/彙總複用原則就是在一個新的對象裡面使用一些已有的對象，使之成為新對象的一部分；新的對象通過向這些對象的委派達到複用已有功能的目的。它的設計原則是：要盡量使用合成/彙總，盡量不要使用繼承。

  最少知識原則（Principle of Least Knowledge，PLK，也叫迪米特法則）：

 　　迪米特法則可以簡單說成：talk only to your immediate friends。 對於面向OOD來說，又被解釋為下面幾種方式：一個軟體實體應當儘可能少的與其他實體發生相互作用。每一個軟體單位對其他的單位都只有最少的知識，而且局限於那些與本單位密切相關的軟體單位。

　　迪米特法則的初衷在於降低類之間的耦合。由於每個類盡量減少對其他類的依賴，因此，很容易使得系統的功能模組功能獨立，相互之間不存在（或很少有）依賴關係。

　　迪米特法則不希望類直接建立直接的接觸。如果真的有需要建立聯絡，也希望能通過它的友元類來轉達。因此，應用迪米特法則有可能造成的一個後果就是：系統中存在大量的中介類，這些類之所以存在完全是為了傳遞類之間的相互調用關係——這在一定程度上增加了系統的複雜度。

  單一職責原則（Single Responsibility Principal， SRP）：

 　　一個類，只有一個引起它變化的原因。應該 只有一個職責。每一個職責都是變化的一個軸線，如果一個類有一個以上的職責，這些職責就耦合在了一起。這會導致脆弱的設計。當一個職責發生變化時，可能會 影響其它的職責。另外，多個職責耦合在一起，會影響複用性。例如：要實現邏輯和介面的分離。

Object-Oriented Principle（物件導向原則）