1 概述 1 概述 本章敘述面向向對象設計的七大原則，七大原則分為：單一職責原則、開閉原則、里氏替換原則、依賴倒置原則、介面隔離原則、合成/聚合復用原則、迪米特法則。 2 七大OO面向對象設計 2 七大OO面向對象設計 2.1 單一職責原則SRP（Simple Responsibility Prin ...
1 概述
本章敘述面向向對象設計的七大原則，七大原則分為：單一職責原則、開閉原則、里氏替換原則、依賴倒置原則、介面隔離原則、合成/聚合復用原則、迪米特法則。
2 七大OO面向對象設計
2.1 單一職責原則SRP（Simple Responsibility Principle）
單一職責原則，就是一個設計元素只做一件事。什麼是“只做一件事”？就是少管閑事。現實中也是如此，如果讓一個人認真的去做一件事，那麼任何人都有信心可以做到很出色。就一個類而言，應該僅有一個引起它變化的原因，如果你能想到兩個或是多個動機去改變一個類，那麼這個類就具有兩個或是多個職責。應該把多餘的職責分離出去，分別在創建一個類去完成每一個職責。
2.2 開閉原則OCP（Open Close Principle）
很簡單，一句話：“Closedfor Modification;Open for Extension",意思是，”對變更關閉；對擴展開放“。開閉原則的動機很簡單：軟體是變化的。一個軟體實體應當對修改關閉，對擴展開放。也就是說，在設計一個模塊的時候，應當對這個模塊可以在不被修改的前提下被擴展。換言之，應當可以在不必修改源代碼的情況下改變這個模塊的行為，在保持系統一定穩定性的基礎上，對系統進行擴展。這是面向對象設計（OOD）的基石，也是最重要的原則。OCP說明瞭軟體設計應該儘可能地是架構穩定而又容易滿足不同的需求。
2.3 里氏替換原則LSP（Liskov Substitution Principle）
a.由BarbarLiskov(芭芭拉.里氏)提出，是繼承復用的基石。
b.嚴格表達:如果每一個類型為T1的對象o1,都有類型為T2的對象o2,使得以T1定義的所有程式P在所有的對象o1都代換稱o2時,程式P的行為沒有變化,那麼類型T2是類型T1的子類型.換言之,一個軟體實體如果使用的是一個基類的話,那麼一定適用於其子類,而且它根本不能察覺出基類對象和子類對象的區別.只有衍生類可以替換基類，軟體單位的功能才能不受影響，基類才能真正被覆用，而衍生類也能夠在基類的基礎上增加新功能。
c.反過來的代換不成立
d.<墨子.小取>中說:"白馬,馬也; 乘白馬,乘馬也.驪馬(黑馬),馬也;乘驪馬,乘馬也."
e.該類西方著名的常式為:正方形是否是長方形的子類(答案是"否")。類似的還有橢圓和圓的關係。
f.應當儘量從抽象類繼承,而不從具體類繼承,一般而言,如果有兩個具體類A,B有繼承關係,那麼一個最簡單的修改方案是建立一個抽象類C,然後讓類A和B成為抽象類C的子類.即如果有一個由繼承關係形成的登記結構的話,那麼在等級結構的樹形圖上面所有的樹葉節點都應當是具體類;而所有的樹枝節點都應當是抽象類或者介面.
g."基於契約設計(DesignBy Constract),簡稱DBC"這項技術對LISKOV代換原則提供了支持.該項技術BertrandMeyer伯特蘭做過詳細的介紹:
使用DBC,類的編寫者顯式地規定針對該類的契約.客戶代碼的編寫者可以通過該契約獲悉可以依賴的行為方式.契約是通過每個方法聲明的前置條件(preconditions)和後置條件(postconditions)來指定的.要使一個方法得以執行,前置條件必須為真.執行完畢後,該方法要保證後置條件為真.就是說,在重新聲明派生類中的常式(routine)時,只能使用相等或者更弱的前置條件來替換原始的前置條件,只能使用相等或者更強的後置條件來替換原始的後置條件.
2.4 依賴倒置原則DIP（Dependency Inversion Principle）
a.表述:抽象不應當依賴於細節,細節應當依賴於抽象.(Programto an interface, not an implementaction)
b.表述二:針對介面編程的意思是說,應當使用介面和抽象類進行變數的類型聲明,參量的類型聲明,方法的返還類型聲明,以及數據類型的轉換等.不要針對實現編程的意思就是說,不應當使用具體類進行變數的類型聲明,參量類型聲明,方法的返還類型聲明,以及數據類型的轉換等.
要保證做到這一點,一個具體的類應等只實現介面和抽象類中聲明過的方法,而不應當給出多餘的方法.
只要一個被引用的對象存在抽象類型,就應當在任何引用此對象的地方使用抽象類型,包括參量的類型聲明,方法返還類型的聲明,屬性變數的類型聲明等.
c.介面與抽象的區別就在於抽象類可以提供某些方法的部分實現,而介面則不可以,這也大概是抽象類唯一的優點.如果向一個抽象類加入一個新的具體方法,那麼所有的子類型一下子就都得到得到了這個新的具體方法,而介面做不到這一點.如果向一個介面加入了一個新的方法的話,所有實現這個介面的類就全部不能通過編譯了,因為它們都沒有實現這個新聲明的方法.這顯然是介面的一個缺點.
d.一個抽象類的實現只能由這個抽象類的子類給出,也就是說,這個實現處在抽象類所定義出的繼承的登記結構中,而由於一般語言都限制一個類只能從最多一個超類繼承,因此將抽象作為類型定義工具的效能大打折扣.
反過來,看介面,就會發現任何一個實現了一個介面所規定的方法的類都可以具有這個介面的類型,而一個類可以實現任意多個介面.
e.從代碼重構的角度上講,將一個單獨的具體類重構成一個介面的實現是很容易的,只需要聲明一個介面,並將重要的方法添加到介面聲明中,然後在具體類定義語句中加上保留字以繼承於該介面就行了.
而作為一個已有的具體類添加一個抽象類作為抽象類型不那麼容易,因為這個具體類有可能已經有一個超類.這樣一來,這個新定義的抽象類只好繼續向上移動,變成這個超類的超類,如此迴圈,最後這個新的抽象類必定處於整個類型等級結構的最上端,從而使登記結構中的所有成員都會受到影響.
f.介面是定義混合類型的理想工具,所為混合類型,就是在一個類的主類型之外的次要類型.一個混合類型表明一個類不僅僅具有某個主類型的行為,而且具有其他的次要行為.
g.聯合使用介面和抽象類:
由於抽象類具有提供預設實現的優點,而介面具有其他所有優點,所以聯合使用兩者就是一個很好的選擇.
首先,聲明類型的工作仍然介面承擔的,但是同時給出的還有一個抽象類,為這個介面給出一個預設實現.其他同屬於這個抽象類型的具體類可以選擇實現這個介面,也可以選擇繼承自這個抽象類.如果一個具體類直接實現這個介面的話,它就必須自行實現所有的介面;相反,如果它繼承自抽象類的話,它可以省去一些不必要的的方法,因為它可以從抽象類中自動得到這些方法的預設實現;如果需要向介面加入一個新的方法的話,那麼只要同時向這個抽象類加入這個方法的一個具體實現就可以了,因為所有繼承自這個抽象類的子類都會從這個抽象類得到這個具體方法.這其實就是預設適配器模式(DefauleAdapter).
h.什麼是高層策略呢?它是應用背後的抽象,是那些不隨具體細節的改變而改變的真理.它是系統內部的系統____隱喻.
2.5 介面隔離原則ISP（Interface Segregation Principle）
a.一個類對另外一個類的依賴是建立在最小的介面上。
b.使用多個專門的介面比使用單一的總介面要好.根據客戶需要的不同,而為不同的客戶端提供不同的服務是一種應當得到鼓勵的做法.就像"看人下菜碟"一樣,要看客人是誰,再提供不同檔次的飯菜.
c.胖介面會導致他們的客戶程式之間產生不正常的並且有害的耦合關係.當一個客戶程式要求該胖介面進行一個改動時,會影響到所有其他的客戶程式.因此客戶程式應該僅僅依賴他們實際需要調用的方法.
2.6 合成/聚合復用原則CARP（Composite/AggregateReuse Principle）
在一個新的對象裡面使用一些已有的對象,使之成為新對象的一部分;新的對象通過這些向對象的委派達到復用已有功能的目的.這個設計原則有另一個簡短的表述:要儘量使用合成/聚合,儘量不要使用繼承.
2.7 迪米特法則（Law of Demeter LoD)又叫做最少知識原則LKP(Least KnowledgePrinciple)
對其他對象有儘可能少的了瞭解.
迪米特法則最初是用來作為面向對象的系統設計風格的一種法則,與1987年秋天由IanHolland在美國東北大學為一個叫做迪米特(Demeter)的項目設計提出的,因此叫做迪米特法則[LIEB89][LIEB86].這條法則實際上是很多著名系統,比如火星登陸軟體系統,木星的歐羅巴衛星軌道飛船的軟體系統的指導設計原則.
沒有任何一個其他的OO設計原則象迪米特法則這樣有如此之多的表述方式,如下幾種:
a.只與你直接的朋友們通信(Onlytalk to your immediate friends)
b.不要跟"陌生人"說話(Don'ttalk to strangers)
c.每一個軟體單位對其他的單位都只有最少的知識,而且局限於那些本單位密切相關的軟體單位.
就是說,如果兩個類不必彼此直接通信,那麼這兩個類就不應當發生直接的相互作用,如果其中的一個類需要調用另一個類的某一個方法的話,可以通過第三者轉發這個調用。
常說的OO五大原則
單一職責原則；開放閉合原則；里氏替換原則；依賴倒置原則；介面隔離原則;
3 參考文獻
【01】《大話設計模式》(中文版)，《design patterns：elements of reusable object-oriented software》(英文版)
【02】《設計模式》（可復用面向對象軟體的基礎）(中文版)，《Design Patterns Elements of Reusable Object-Oriented Software》(英文版)
【03】《Head First設計模式》(中文版)， 《Head First Design Patterns》(英文版)
【04】《C#設計模式》(中文版)，《C# Design Patterns:A Tutorial》(英文版)
【05】《Java企業設計模式》(中文版)，《Java Enterprise Design Patterns》(英文版)
【06】 《UML和模式應用》（面向對象分析與設計導論）(中文版)， 《Applying UML and Patterns:An Introduction to Object-Oriented Analysis and Design》(英文版)
【07】 《設計模式解析》(中文版)，《Design Patterns Explained:A New Perspective on Object-Oriented Design》
【08】 《.NET 設計規範--.NET約定、慣用法與模式》(中文版)，《Framework Design Guidelines : Conventions, Idioms, and Patterns for Reusable .NET Libraries》(英文版)
【09】 《重構與模式》(中文版)，《Refactoring to Patterns》(英文版)
【10】 《設計模式解析》(中文版)，《Design Patterns Explained:A New Perspective on Object-Oriented Design ,Second Edition》(英文版)
【11】 《深入淺出設計模式》(中文版)，（C#/Java版）
【12】 《多線程與併發處理》
【13】 《企業應用架構模式》 (中文版)，《Patterns of Enterprise Application Architecture》(英文版)
4 版權
- 感謝您的閱讀，若有不足之處，歡迎指教，共同學習、共同進步。
- 博主網址：http://www.cnblogs.com/wangjiming/。
- 極少部分文章利用讀書、參考、引用、抄襲、複製和粘貼等多種方式整合而成的，大部分為原創。
- 如您喜歡，麻煩推薦一下；如您有新想法，歡迎提出，郵箱：[email protected]。
- 可以轉載該博客，但必須著名博客來源。
