面向對象設計的7大原則

7大原則

1.開閉原則
2.里氏替換原則
3.依賴倒置原則
4.單一職責原則
5.接口隔離原則
6.迪米特法則
7.合成複用原則

開閉原則的定義

開閉原則(Open Closed Principle,OCP)由勃蘭特·梅耶(Bertrand Meyer)提出,他在 1988 年的著作《面向對象軟件構造》(Object Oriented Software Construction)中提出:軟件實體應當對擴展開放,對修改關閉(Software entities should be open for extension,but closed for modification),這就是開閉原則的經典定義。

這裏的軟件實體包括以下幾個部分:
項目中劃分出的模塊
類與接口
方法

開閉原則的含義是:當應用的需求改變時,在不修改軟件實體的源代碼或者二進制代碼的前提下,可以擴展模塊的功能,使其滿足新的需求。

開閉原則的作用

開閉原則是面向對象程序設計的終極目標,它使軟件實體擁有一定的適應性和靈活性的同時具備穩定性和延續性。具體來說,其作用如下。

  1. 對軟件測試的影響
    軟件遵守開閉原則的話,軟件測試時只需要對擴展的代碼進行測試就可以了,因爲原有的測試代碼仍然能夠正常運行。
  2. 可以提高代碼的可複用性
    粒度越小,被複用的可能性就越大;在面向對象的程序設計中,根據原子和抽象編程可以提高代碼的可複用性。
  3. 可以提高軟件的可維護性
    遵守開閉原則的軟件,其穩定性高和延續性強,從而易於擴展和維護。

里氏替換原則的定義

里氏替換原則(Liskov Substitution Principle,LSP)由麻省理工學院計算機科學實驗室的里斯科夫(Liskov)女士在 1987 年的“面向對象技術的高峯會議”(OOPSLA)上發表的一篇文章《數據抽象和層次》(Data Abstraction and Hierarchy)裏提出來的,她提出:繼承必須確保超類所擁有的性質在子類中仍然成立(Inheritance should ensure that any property proved about supertype objects also holds for subtype objects)。

里氏替換原則主要闡述了有關繼承的一些原則,也就是什麼時候應該使用繼承,什麼時候不應該使用繼承,以及其中蘊含的原理。里氏替換原是繼承複用的基礎,它反映了基類與子類之間的關係,是對開閉原則的補充,是對實現抽象化的具體步驟的規範。

里氏替換原則的作用

里氏替換原則的主要作用如下。
里氏替換原則是實現開閉原則的重要方式之一。
它克服了繼承中重寫父類造成的可複用性變差的缺點。
它是動作正確性的保證。即類的擴展不會給已有的系統引入新的錯誤,降低了代碼出錯的可能性。

依賴倒置原則的定義

依賴倒置原則(Dependence Inversion Principle,DIP)是 Object Mentor 公司總裁羅伯特·馬丁(Robert C.Martin)於 1996 年在 C++ Report 上發表的文章。

依賴倒置原則的原始定義爲:高層模塊不應該依賴低層模塊,兩者都應該依賴其抽象;抽象不應該依賴細節,細節應該依賴抽象(High level modules shouldnot depend upon low level modules.Both should depend upon abstractions.Abstractions should not depend upon details. Details should depend upon abstractions)。其核心思想是:要面向接口編程,不要面向實現編程。

依賴倒置原則是實現開閉原則的重要途徑之一,它降低了客戶與實現模塊之間的耦合。

由於在軟件設計中,細節具有多變性,而抽象層則相對穩定,因此以抽象爲基礎搭建起來的架構要比以細節爲基礎搭建起來的架構要穩定得多。這裏的抽象指的是接口或者抽象類,而細節是指具體的實現類。

使用接口或者抽象類的目的是制定好規範和契約,而不去涉及任何具體的操作,把展現細節的任務交給它們的實現類去完成。

依賴、倒置原則的作用

依賴倒置原則的主要作用如下。
依賴倒置原則可以降低類間的耦合性。
依賴倒置原則可以提高系統的穩定性。
依賴倒置原則可以減少並行開發引起的風險。
依賴倒置原則可以提高代碼的可讀性和可維護性。

單一職責原則的定義

單一職責原則(Single Responsibility Principle,SRP)又稱單一功能原則,由羅伯特·C.馬丁(Robert C. Martin)於《敏捷軟件開發:原則、模式和實踐》一書中提出的。這裏的職責是指類變化的原因,單一職責原則規定一個類應該有且僅有一個引起它變化的原因,否則類應該被拆分(There should never be more than one reason for a class to change)。

該原則提出對象不應該承擔太多職責,如果一個對象承擔了太多的職責,至少存在以下兩個缺點:
一個職責的變化可能會削弱或者抑制這個類實現其他職責的能力;
當客戶端需要該對象的某一個職責時,不得不將其他不需要的職責全都包含進來,從而造成冗餘代碼或代碼的浪費。

單一職責原則的優點

單一職責原則的核心就是控制類的粒度大小、將對象解耦、提高其內聚性。如果遵循單一職責原則將有以下優點。
降低類的複雜度。一個類只負責一項職責,其邏輯肯定要比負責多項職責簡單得多。
提高類的可讀性。複雜性降低,自然其可讀性會提高。
提高系統的可維護性。可讀性提高,那自然更容易維護了。
變更引起的風險降低。變更是必然的,如果單一職責原則遵守得好,當修改一個功能時,可以顯著降低對其他功能的影響。

接口隔離原則的定義

接口隔離原則(Interface Segregation Principle,ISP)要求程序員儘量將臃腫龐大的接口拆分成更小的和更具體的接口,讓接口中只包含客戶感興趣的方法。

2002 年羅伯特·C.馬丁給“接口隔離原則”的定義是:客戶端不應該被迫依賴於它不使用的方法(Clients should not be forced to depend on methods they do not use)。該原則還有另外一個定義:一個類對另一個類的依賴應該建立在最小的接口上(The dependency of one class to another one should depend on the smallest possible interface)。

以上兩個定義的含義是:要爲各個類建立它們需要的專用接口,而不要試圖去建立一個很龐大的接口供所有依賴它的類去調用。

接口隔離原則和單一職責都是爲了提高類的內聚性、降低它們之間的耦合性,體現了封裝的思想,但兩者是不同的:
單一職責原則注重的是職責,而接口隔離原則注重的是對接口依賴的隔離。
單一職責原則主要是約束類,它針對的是程序中的實現和細節;接口隔離原則主要約束接口,主要針對抽象和程序整體框架的構建。

接口隔離原則的優點

接口隔離原則是爲了約束接口、降低類對接口的依賴性,遵循接口隔離原則有以下 5 個優點。
將臃腫龐大的接口分解爲多個粒度小的接口,可以預防外來變更的擴散,提高系統的靈活性和可維護性。
接口隔離提高了系統的內聚性,減少了對外交互,降低了系統的耦合性。
如果接口的粒度大小定義合理,能夠保證系統的穩定性;但是,如果定義過小,則會造成接口數量過多,使設計複雜化;如果定義太大,靈活性降低,無法提供定製服務,給整體項目帶來無法預料的風險。
使用多個專門的接口還能夠體現對象的層次,因爲可以通過接口的繼承,實現對總接口的定義。
能減少項目工程中的代碼冗餘。過大的大接口裏面通常放置許多不用的方法,當實現這個接口的時候,被迫設計冗餘的代碼。

迪米特法則的定義

迪米特法則(Law of Demeter,LoD)又叫作最少知識原則(Least Knowledge Principle,LKP),產生於 1987 年美國東北大學(Northeastern University)的一個名爲迪米特(Demeter)的研究項目,由伊恩·荷蘭(Ian Holland)提出,被 UML 創始者之一的布奇(Booch)普及,後來又因爲在經典著作《程序員修煉之道》(The Pragmatic Programmer)提及而廣爲人知。

迪米特法則的定義是:只與你的直接朋友交談,不跟“陌生人”說話(Talk only to your immediate friends and not to strangers)。其含義是:如果兩個軟件實體無須直接通信,那麼就不應當發生直接的相互調用,可以通過第三方轉發該調用。其目的是降低類之間的耦合度,提高模塊的相對獨立性。

迪米特法則中的“朋友”是指:當前對象本身、當前對象的成員對象、當前對象所創建的對象、當前對象的方法參數等,這些對象同當前對象存在關聯、聚合或組合關係,可以直接訪問這些對象的方法。

迪米特法則的優點

迪米特法則要求限制軟件實體之間通信的寬度和深度,正確使用迪米特法則將有以下兩個優點。
降低了類之間的耦合度,提高了模塊的相對獨立性。
由於親合度降低,從而提高了類的可複用率和系統的擴展性。

但是,過度使用迪米特法則會使系統產生大量的中介類,從而增加系統的複雜性,使模塊之間的通信效率降低。所以,在釆用迪米特法則時需要反覆權衡,確保高內聚和低耦合的同時,保證系統的結構清晰。

合成複用原則的定義

合成複用原則(Composite Reuse Principle,CRP)又叫組合/聚合複用原則(Composition/Aggregate Reuse Principle,CARP)。它要求在軟件複用時,要儘量先使用組合或者聚合等關聯關係來實現,其次才考慮使用繼承關係來實現。

如果要使用繼承關係,則必須嚴格遵循里氏替換原則。合成複用原則同里氏替換原則相輔相成的,兩者都是開閉原則的具體實現規範。

合成複用原則的重要性

通常類的複用分爲繼承複用和合成複用兩種,繼承複用雖然有簡單和易實現的優點,但它也存在以下缺點。
繼承複用破壞了類的封裝性。因爲繼承會將父類的實現細節暴露給子類,父類對子類是透明的,所以這種複用又稱爲“白箱”複用。
子類與父類的耦合度高。父類的實現的任何改變都會導致子類的實現發生變化,這不利於類的擴展與維護。
它限制了複用的靈活性。從父類繼承而來的實現是靜態的,在編譯時已經定義,所以在運行時不可能發生變化。

採用組合或聚合複用時,可以將已有對象納入新對象中,使之成爲新對象的一部分,新對象可以調用已有對象的功能,它有以下優點。
它維持了類的封裝性。因爲成分對象的內部細節是新對象看不見的,所以這種複用又稱爲“黑箱”複用。
新舊類之間的耦合度低。這種複用所需的依賴較少,新對象存取成分對象的唯一方法是通過成分對象的接口。
複用的靈活性高。這種複用可以在運行時動態進行,新對象可以動態地引用與成分對象類型相同的對象。

轉自 http://c.biancheng.net/view/1322.html

源站包含更多內容。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章