設計模式--7種面向對象設計原則

軟件設計模式的產生背景

1995 年,艾瑞克·伽馬(ErichGamma)、理査德·海爾姆(Richard Helm)、拉爾夫·約翰森(Ralph Johnson)、約翰·威利斯迪斯(John Vlissides)等 4 位做者合做出版了《設計模式:可複用面向對象軟件的基礎》(Design Patterns: Elements of Reusable Object-Oriented Software)一書,這是設計模式領域裏程碑的事件,致使了軟件設計模式的突破。這 4 位做者在軟件開發領域裏也以他們的「四人組」(Gang of Four,GoF)匿名著稱。程序員

軟件設計模式的概念與意義

有關軟件設計模式的定義不少,有些從模式的特色來講明,有些從模式的做用來講明。本教程給出的定義是大多數學者公認的,從如下兩個方面來講明。算法

1. 軟件設計模式的概念

軟件設計模式(Software Design Pattern),又稱設計模式,是一套被反覆使用、多數人知曉的、通過分類編目的、代碼設計經驗的總結。它描述了在軟件設計過程當中的一些不斷重複發生的問題,以及該問題的解決方案。也就是說,它是解決特定問題的一系列套路,是前輩們的代碼設計經驗的總結,具備必定的廣泛性,能夠反覆使用。其目的是爲了提升代碼的可重用性、代碼的可讀性和代碼的可靠性。編程

2. 學習設計模式的意義

設計模式的本質是面向對象設計原則的實際運用,是對類的封裝性、繼承性和多態性以及類的關聯關係和組合關係的充分理解。正確使用設計模式具備如下優勢:設計模式

  • 能夠提升程序員的思惟能力、編程能力和設計能力。架構

  • 使程序設計更加標準化、代碼編制更加工程化,使軟件開發效率大大提升,從而縮短軟件的開發週期。框架

  • 使設計的代碼可重用性高、可讀性強、可靠性高、靈活性好、可維護性強。ide

固然,軟件設計模式只是一個引導。在具體的軟件開發中,必須根據設計的應用系統的特色和要求來恰當選擇。對於簡單的程序開發,可能寫一個簡單的算法要比引入某種設計模式更加容易。但對大項目的開發或者框架設計,用設計模式來組織代碼顯然更好。學習

軟件設計模式的基本要素

軟件設計模式令人們能夠更加簡單方便地複用成功的設計和體系結構,它一般包含如下幾個基本要素:模式名稱、別名、動機、問題、解決方案、效果、結構、模式角色、合做關係、實現方法、適用性、已知應用、例程、模式擴展和相關模式等,其中最關鍵的元素包括如下 4 個主要部分。測試

1. 模式名稱

每個模式都有本身的名字,一般用一兩個詞來描述,能夠根據模式的問題、特色、解決方案、功能和效果來命名。模式名稱(PatternName)有助於咱們理解和記憶該模式,也方便咱們來討論本身的設計。設計

2. 問題

問題(Problem)描述了該模式的應用環境,即什麼時候使用該模式。它解釋了設計問題和問題存在的來龍去脈,以及必須知足的一系列先決條件。

3. 解決方案

模式問題的解決方案(Solution)包括設計的組成成分、它們之間的相互關係及各自的職責和協做方式。由於模式就像一個模板,可應用於多種不一樣場合,因此解決方案並不描述一個特定而具體的設計或實現,而是提供設計問題的抽象描述和怎樣用一個具備通常意義的元素組合(類或對象的 組合)來解決這個問題。

4. 效果

描述了模式的應用效果以及使用該模式應該權衡的問題,即模式的優缺點。主要是對時間和空間的衡量,以及該模式對系統的靈活性、擴充性、可移植性的影響,也考慮其實現問題。顯式地列出這些效果(Consequence)對理解和評價這些模式有很大的幫助。

七種面向對象設計原則

在軟件開發中,爲了提升軟件系統的可維護性和可複用性,增長軟件的可擴展性和靈活性,程序員要儘可能根據 7 條原則來開發程序,從而提升軟件開發效率、節約軟件開發成本和維護成本。咱們將在下面的依次來介紹這 7 條原則。

(一)開閉原則

1. 開閉原則的定義

開閉原則(Open Closed Principle,OCP)由勃蘭特·梅耶(Bertrand Meyer)提出,他在 1988 年的著做《面向對象軟件構造》(Object Oriented Software Construction)中提出:軟件實體(包括項目中劃分出的模塊、類與接口和方法)應當對擴展開放,對修改關閉(Software entities should be open for extension,but closed for modification),這就是開閉原則的經典定義。

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

2. 開閉原則的做用

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

  • 對軟件測試的影響

軟件遵照開閉原則的話,軟件測試時只須要對擴展的代碼進行測試就能夠了,由於原有的測試代碼仍然可以正常運行。

  • 能夠提升代碼的可複用性

粒度越小,被複用的可能性就越大;在面向對象的程序設計中,根據原子和抽象編程能夠提升代碼的可複用性。

  • 能夠提升軟件的可維護性

遵照開閉原則的軟件,其穩定性高和延續性強,從而易於擴展和維護。

3. 開閉原則的實現方法

能夠經過「抽象約束、封裝變化」來實現開閉原則,即經過接口或者抽象類爲軟件實體定義一個相對穩定的抽象層,而將相同的可變因素封裝在相同的具體實現類中。

由於抽象靈活性好,適應性廣,只要抽象的合理,能夠基本保持軟件架構的穩定。而軟件中易變的細節能夠從抽象派生來的實現類來進行擴展,當軟件須要發生變化時,只須要根據需求從新派生一個實現類來擴展就能夠了。

(二)里氏替換原則

1. 里氏替換原則的定義

里氏替換原則(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)。

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

2. 里氏替換原則的做用

里氏替換原則的主要做用以下。

  • 里氏替換原則是實現開閉原則的重要方式之一。

  • 它克服了繼承中重寫父類形成的可複用性變差的缺點。

  • 它是動做正確性的保證。即類的擴展不會給已有的系統引入新的錯誤,下降了代碼出錯的可能性。

3. 里氏替換原則的實現方法

里氏替換原則通俗來說就是:子類能夠擴展父類的功能,但不能改變父類原有的功能。也就是說:子類繼承父類時,除添加新的方法完成新增功能外,儘可能不要重寫父類的方法。

若是經過重寫父類的方法來完成新的功能,這樣寫起來雖然簡單,可是整個繼承體系的可複用性會比較差,特別是運用多態比較頻繁時,程序運行出錯的機率會很是大。

若是程序違背了里氏替換原則,則繼承類的對象在基類出現的地方會出現運行錯誤。這時其修正方法是:取消原來的繼承關係,從新設計它們之間的關係。
關於里氏替換原則的例子,最有名的是「正方形不是長方形」。固然,生活中也有不少相似的例子,例如,企鵝、鴕鳥和幾維鳥從生物學的角度來劃分,它們屬於鳥類;但從類的繼承關係來看,因爲它們不能繼承「鳥」會飛的功能,因此它們不能定義成「鳥」的子類。

(三)依賴倒置原則

1. 依賴倒置原則的定義

依賴倒置原則(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)。其核心思想是:要面向接口編程,不要面向實現編程。
依賴倒置原則是實現開閉原則的重要途徑之一,它下降了客戶與實現模塊之間的耦合。
因爲在軟件設計中,細節具備多變性,而抽象層則相對穩定,所以以抽象爲基礎搭建起來的架構要比以細節爲基礎搭建起來的架構要穩定得多。這裏的抽象指的是接口或者抽象類,而細節是指具體的實現類。
使用接口或者抽象類的目的是制定好規範和契約,而不去涉及任何具體的操做,把展示細節的任務交給它們的實現類去完成。

2. 依賴倒置原則的做用

依賴倒置原則的主要做用以下:

  • 依賴倒置原則能夠下降類間的耦合性。

  • 依賴倒置原則能夠提升系統的穩定性。

  • 依賴倒置原則能夠減小並行開發引發的風險。

  • 依賴倒置原則能夠提升代碼的可讀性和可維護性。

3. 依賴倒置原則的實現方法

依賴倒置原則的目的是經過要面向接口的編程來下降類間的耦合性,因此咱們在實際編程中只要遵循如下4點,就能在項目中知足這個規則。

  • 每一個類儘可能提供接口或抽象類,或者二者都具有。

  • 變量的聲明類型儘可能是接口或者是抽象類。

  • 任何類都不該該從具體類派生。

  • 使用繼承時儘可能遵循里氏替換原則。

(四)單一職責原則

1. 單一職責原則的定義

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

該原則提出對象不該該承擔太多職責,若是一個對象承擔了太多的職責,至少存在如下兩個缺點:

  • 一個職責的變化可能會削弱或者抑制這個類實現其餘職責的能力;

  • 當客戶端須要該對象的某一個職責時,不得不將其餘不須要的職責全都包含進來,從而形成冗餘代碼或代碼的浪費。

2. 單一職責原則的做用

單一職責原則的核心就是控制類的粒度大小、將對象解耦、提升其內聚性。若是遵循單一職責原則將有如下優勢:

  • 下降類的複雜度。一個類只負責一項職責,其邏輯確定要比負責多項職責簡單得多。

  • 提升類的可讀性。複雜性下降,天然其可讀性會提升。

  • 提升系統的可維護性。可讀性提升,那天然更容易維護了。

  • 變動引發的風險下降。變動是必然的,若是單一職責原則遵照得好,當修改一個功能時,能夠顯著下降對其餘功能的影響。

3. 單一職責原則的實現方法

單一職責原則是最簡單但又最難運用的原則,須要設計人員發現類的不一樣職責並將其分離,再封裝到不一樣的類或模塊中。而發現類的多重職責須要設計人員具備較強的分析設計能力和相關重構經驗。

(五)接口隔離原則

1. 接口隔離原則的定義

接口隔離原則(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)。

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

接口隔離原則和單一職責都是爲了提升類的內聚性、下降它們之間的耦合性,體現了封裝的思想,但二者是不一樣的:

  • 單一職責原則注重的是職責,而接口隔離原則注重的是對接口依賴的隔離。

  • 單一職責原則主要是約束類,它針對的是程序中的實現和細節;接口隔離原則主要約束接口,主要針對抽象和程序總體框架的構建。

2. 接口隔離原則的做用

接口隔離原則是爲了約束接口、下降類對接口的依賴性,遵循接口隔離原則有如下 5 個優勢。

  1. 將臃腫龐大的接口分解爲多個粒度小的接口,能夠預防外來變動的擴散,提升系統的靈活性和可維護性。

  2. 接口隔離提升了系統的內聚性,減小了對外交互,下降了系統的耦合性。

  3. 若是接口的粒度大小定義合理,可以保證系統的穩定性;可是,若是定義太小,則會形成接口數量過多,使設計複雜化;若是定義太大,靈活性下降,沒法提供定製服務,給總體項目帶來沒法預料的風險。

  4. 使用多個專門的接口還可以體現對象的層次,由於能夠經過接口的繼承,實現對總接口的定義。

  5. 能減小項目工程中的代碼冗餘。過大的大接口裏面一般放置許多不用的方法,當實現這個接口的時候,被迫設計冗餘的代碼。

3. 接口隔離原則的實現方法

在具體應用接口隔離原則時,應該根據如下幾個規則來衡量:

  • 接口儘可能小,可是要有限度。一個接口只服務於一個子模塊或業務邏輯。

  • 爲依賴接口的類定製服務。只提供調用者須要的方法,屏蔽不須要的方法。

  • 瞭解環境,拒絕盲從。每一個項目或產品都有選定的環境因素,環境不一樣,接口拆分的標準就不一樣深刻了解業務邏輯。

  • 提升內聚,減小對外交互。使接口用最少的方法去完成最多的事情。

(六)迪米特法則

1. 迪米特法則的定義

迪米特法則(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)。其含義是:若是兩個軟件實體無須直接通訊,那麼就不該當發生直接的相互調用,能夠經過第三方轉發該調用。其目的是下降類之間的耦合度,提升模塊的相對獨立性。

迪米特法則中的「朋友」是指:當前對象自己、當前對象的成員對象、當前對象所建立的對象、當前對象的方法參數等,這些對象同當前對象存在關聯、聚合或組合關係,能夠直接訪問這些對象的方法。

2. 迪米特法則的優勢

迪米特法則要求限制軟件實體之間通訊的寬度和深度,正確使用迪米特法則將有如下兩個優勢。

  • 下降了類之間的耦合度,提升了模塊的相對獨立性。

  • 因爲親和度下降,從而提升了類的可複用率和系統的擴展性。


可是,過分使用迪米特法則會使系統產生大量的中介類,從而增長系統的複雜性,使模塊之間的通訊效率下降。因此,在釆用迪米特法則時須要反覆權衡,確保高內聚和低耦合的同時,保證系統的結構清晰。

3. 迪米特法則的實現方法

從迪米特法則的定義和特色可知,它強調如下兩點:

  • 從依賴者的角度來講,只依賴應該依賴的對象。

  • 從被依賴者的角度說,只暴露應該暴露的方法。


因此,在運用迪米特法則時要注意如下 6 點:

  • 在類的劃分上,應該建立弱耦合的類。類與類之間的耦合越弱,就越有利於實現可複用的目標。

  • 在類的結構設計上,儘可能下降類成員的訪問權限。

  • 在類的設計上,優先考慮將一個類設置成不變類。

  • 在對其餘類的引用上,將引用其餘對象的次數降到最低。

  • 不暴露類的屬性成員,而應該提供相應的訪問器(set 和 get 方法)。

  • 謹慎使用序列化(Serializable)功能。

(七)合成複用原則

1. 合成複用原則的定義

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

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

2. 合成複用原則的重要性

一般類的複用分爲繼承複用和合成複用兩種,繼承複用雖然有簡單和易實現的優勢,但它也存在如下缺點:

  • 繼承複用破壞了類的封裝性。由於繼承會將父類的實現細節暴露給子類,父類對子類是透明的,因此這種複用又稱爲「白箱」複用。

  • 子類與父類的耦合度高。父類的實現的任何改變都會致使子類的實現發生變化,這不利於類的擴展與維護。

  • 它限制了複用的靈活性。從父類繼承而來的實現是靜態的,在編譯時已經定義,因此在運行時不可能發生變化。


採用組合或聚合複用時,能夠將已有對象歸入新對象中,使之成爲新對象的一部分,新對象能夠調用已有對象的功能,它有如下優勢:

  • 它維持了類的封裝性。由於成分對象的內部細節是新對象看不見的,因此這種複用又稱爲「黑箱」複用。

  • 新舊類之間的耦合度低。這種複用所需的依賴較少,新對象存取成分對象的惟一方法是經過成分對象的接口。

  • 複用的靈活性高。這種複用能夠在運行時動態進行,新對象能夠動態地引用與成分對象類型相同的對象。

3. 合成複用原則的實現方法

合成複用原則是經過將已有的對象歸入新對象中,做爲新對象的成員對象來實現的,新對象能夠調用已有對象的功能,從而達到複用。

以上咱們介紹了七種面向對象設計原則,下一篇將會介紹建立型模式中的單例與多例模式。


感謝閱讀!


喜歡本文的朋友,歡迎關注「isevena

相關文章
相關標籤/搜索