【設計模式系列】之OO面向對象設計七大原則

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/。
• 極少部分文章利用讀書、參考、引用、抄襲、複製和粘貼等多種方式整合而成的，大部分爲原創。
• 如您喜歡，麻煩推薦一下；如您有新想法，歡迎提出，郵箱：2016177728@qq.com。
• 能夠轉載該博客，但必須著名博客來源。