02 第2章 面向?qū)ο笤O(shè)計原則.ppt_第1頁
02 第2章 面向?qū)ο笤O(shè)計原則.ppt_第2頁
02 第2章 面向?qū)ο笤O(shè)計原則.ppt_第3頁
02 第2章 面向?qū)ο笤O(shè)計原則.ppt_第4頁
02 第2章 面向?qū)ο笤O(shè)計原則.ppt_第5頁
已閱讀5頁,還剩51頁未讀, 繼續(xù)免費閱讀

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進行舉報或認領(lǐng)

文檔簡介

1、第2章,面向?qū)ο笤O(shè)計原則,劉 偉 weiliu_,本章教學內(nèi)容,面向?qū)ο笤O(shè)計原則概述 單一職責原則 開閉原則 里氏代換原則 依賴倒轉(zhuǎn)原則 接口隔離原則 合成復用原則 迪米特法則,面向?qū)ο笤O(shè)計原則概述,軟件的可維護性和可復用性 知名軟件大師Robert C.Martin認為一個可維護性(Maintainability) 較低的軟件設(shè)計,通常由于如下4個原因造成: 過于僵硬(Rigidity) 過于脆弱(Fragility) 復用率低(Immobility) 黏度過高(Viscosity),Robert C.Martin,面向?qū)ο笤O(shè)計原則概述,軟件的可維護性和可復用性 軟件工程和建模大師Peter

2、 Coad認為,一個好的系統(tǒng)設(shè)計應該具備如下三個性質(zhì): 可擴展性(Extensibility) 靈活性(Flexibility) 可插入性(Pluggability),Peter Coad,面向?qū)ο笤O(shè)計原則概述,軟件的可維護性和可復用性 軟件的復用(Reuse)或重用擁有眾多優(yōu)點,如可以提高軟件的開發(fā)效率,提高軟件質(zhì)量,節(jié)約開發(fā)成本,恰當?shù)膹陀眠€可以改善系統(tǒng)的可維護性。 面向?qū)ο笤O(shè)計復用的目標在于實現(xiàn)支持可維護性的復用。 在面向?qū)ο蟮脑O(shè)計里面,可維護性復用都是以面向?qū)ο笤O(shè)計原則為基礎(chǔ)的,這些設(shè)計原則首先都是復用的原則,遵循這些設(shè)計原則可以有效地提高系統(tǒng)的復用性,同時提高系統(tǒng)的可維護性。,面向?qū)?/p>

3、象設(shè)計原則概述,軟件的可維護性和可復用性 面向?qū)ο笤O(shè)計原則和設(shè)計模式也是對系統(tǒng)進行合理重構(gòu)的指南針,重構(gòu)(Refactoring)是在不改變軟件現(xiàn)有功能的基礎(chǔ)上,通過調(diào)整程序代碼改善軟件的質(zhì)量、性能,使其程序的設(shè)計模式和架構(gòu)更趨合理,提高軟件的擴展性和維護性。,Martin Fowler,面向?qū)ο笤O(shè)計原則概述,面向?qū)ο笤O(shè)計原則簡介 常用的面向?qū)ο笤O(shè)計原則包括7個,這些原則并不是孤立存在的,它們相互依賴,相互補充。,單一職責原則,單一職責原則定義 單一職責原則(Single Responsibility Principle, SRP)定義如下: 一個對象應該只包含單一的職責,并且該職責被完整地封

4、裝在一個類中。 其英文定義為: Every object should have a single responsibility, and that responsibility should be entirely encapsulated by the class. 另一種定義方式如下: 就一個類而言,應該僅有一個引起它變化的原因。 其英文定義為: There should never be more than one reason for a class to change.,單一職責原則,單一職責原則分析 一個類(或者大到模塊,小到方法)承擔的職責越多,它被復用的可能性越小,而且如果一

5、個類承擔的職責過多,就相當于將這些職責耦合在一起,當其中一個職責變化時,可能會影響其他職責的運作。 類的職責主要包括兩個方面:數(shù)據(jù)職責和行為職責,數(shù)據(jù)職責通過其屬性來體現(xiàn),而行為職責通過其方法來體現(xiàn)。 單一職責原則是實現(xiàn)高內(nèi)聚、低耦合的指導方針,在很多代碼重構(gòu)手法中都能找到它的存在,它是最簡單但又最難運用的原則,需要設(shè)計人員發(fā)現(xiàn)類的不同職責并將其分離,而發(fā)現(xiàn)類的多重職責需要設(shè)計人員具有較強的分析設(shè)計能力和相關(guān)重構(gòu)經(jīng)驗。,單一職責原則,單一職責原則實例 實例說明 某基于Java的C/S系統(tǒng)的“登錄功能”通過如下登錄類(Login)實現(xiàn): 現(xiàn)使用單一職責原則對其進行重構(gòu)。,單一職責原則,單一職責原

6、則實例 實例解析,開閉原則,開閉原則定義 開閉原則(Open-Closed Principle, OCP)定義如下: 一個軟件實體應當對擴展開放,對修改關(guān)閉。也就是說在設(shè)計一個模塊的時候,應當使這個模塊可以在不被修改的前提下被擴展,即實現(xiàn)在不修改源代碼的情況下改變這個模塊的行為。 其英文定義為: Software entities should be open for extension, but closed for modification.,開閉原則,開閉原則分析 開閉原則由Bertrand Meyer于1988年提出,它是面向?qū)ο笤O(shè)計中最重要的原則之一。 在開閉原則的定義中,軟件實體可

7、以指一個軟件模塊、一個由多個類組成的局部結(jié)構(gòu)或一個獨立的類。,開閉原則,開閉原則分析 抽象化是開閉原則的關(guān)鍵。 開閉原則還可以通過一個更加具體的“對可變性封裝原則”來描述,對可變性封裝原則(Principle of Encapsulation of Variation, EVP)要求找到系統(tǒng)的可變因素并將其封裝起來。,開閉原則,開閉原則實例 實例說明 某圖形界面系統(tǒng)提供了各種不同形狀的按鈕,客戶端代碼可針對這些按鈕進行編程,用戶可能會改變需求要求使用不同的按鈕,原始設(shè)計方案如圖所示: 現(xiàn)對該系統(tǒng)進行重構(gòu),使之滿足開閉原則的要求。,開閉原則,開閉原則實例 實例解析,里氏代換原則,里氏代換原則定義

8、 里氏代換原則(Liskov Substitution Principle, LSP)有兩種定義方式,第一種定義方式相對嚴格,其定義如下: 如果對每一個類型為S的對象o1,都有類型為T的對象o2,使得以T定義的所有程序P在所有的對象o1都代換成o2時,程序P的行為沒有變化,那么類型S是類型T的子類型。 其英文定義為: If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unc

9、hanged when o1 is substituted for o2 then S is a subtype of T. 第二種更容易理解的定義方式如下: 所有引用基類(父類)的地方必須能透明地使用其子類的對象。 其英文定義為: Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.,里氏代換原則,里氏代換原則分析 里氏代換原則由2008年圖靈獎得主、美國第一位計算機科學女博士、麻省理工學院教授Ba

10、rbara Liskov和卡內(nèi)基.梅隆大學Jeannette Wing教授于1994年提出。其原文如下:Let q(x) be a property provable about objects x of type T. Then q(y) should be true for objects y of type S where S is a subtype of T.,芭芭拉利斯科夫(Barbara Liskov),美國計算機科學家,2008年圖靈獎得主,2004年約翰.馮諾依曼獎得主,美國工程院院士,美國藝術(shù)與科學院院士,美國計算機協(xié)會會士?,F(xiàn)任麻省理工學院電子電氣與計算機科學系教授。她是

11、美國第一個計算機科學女博士。,周以真(Jeannette M. Wing),美國計算機科學家,卡內(nèi)基.梅隆大學教授,美國國家自然基金會計算與信息科學工程部助理部長,ACM和IEEE會士。,里氏代換原則,里氏代換原則分析 里氏代換原則可以通俗表述為:在軟件中如果能夠使用基類對象,那么一定能夠使用其子類對象。把基類都替換成它的子類,程序?qū)⒉粫a(chǎn)生任何錯誤和異常,反過來則不成立,如果一個軟件實體使用的是一個子類的話,那么它不一定能夠使用基類。 里氏代換原則是實現(xiàn)開閉原則的重要方式之一,由于使用基類對象的地方都可以使用子類對象,因此在程序中盡量使用基類類型來對對象進行定義,而在運行時再確定其子類類型,

12、用子類對象來替換父類對象。,里氏代換原則,里氏代換原則分析,喜歡動物喜歡貓 因為貓是動物 ,里氏代換原則,里氏代換原則實例 實例說明 某系統(tǒng)需要實現(xiàn)對重要數(shù)據(jù)(如用戶密碼)的加密處理,在數(shù)據(jù)操作類(DataOperator)中需要調(diào)用加密類中定義的加密算法,系統(tǒng)提供了兩個不同的加密類,CipherA和CipherB,它們實現(xiàn)不同的加密方法,在DataOperator中可以選擇其中的一個實現(xiàn)加密操作。如圖所示:,里氏代換原則,里氏代換原則實例 實例說明 如果需要更換一個加密算法類或者增加并使用一個新的加密算法類,如將CipherA改為CipherB,則需要修改客戶類Client和數(shù)據(jù)操作類Dat

13、aOperator的源代碼,違背了開閉原則。 現(xiàn)使用里氏代換原則對其進行重構(gòu),使得系統(tǒng)可以靈活擴展,符合開閉原則。,里氏代換原則,里氏代換原則實例 實例解析,依賴倒轉(zhuǎn)原則,依賴倒轉(zhuǎn)原則定義 依賴倒轉(zhuǎn)原則(Dependence Inversion Principle, DIP)的定義如下: 高層模塊不應該依賴低層模塊,它們都應該依賴抽象。抽象不應該依賴于細節(jié),細節(jié)應該依賴于抽象。 其英文定義為: High level modules should not depend upon low level modules, both should depend upon abstractions. Ab

14、stractions should not depend upon details, details should depend upon abstractions. 另一種表述為: 要針對接口編程,不要針對實現(xiàn)編程。 其英文定義為: Program to an interface, not an implementation.,依賴倒轉(zhuǎn)原則,依賴倒轉(zhuǎn)原則分析 依賴倒轉(zhuǎn)原則是Robert C. Martin在1996年為C+ Reporter所寫的專欄Engineering Notebook的第三篇,后來加入到他在2002年出版的經(jīng)典著作Agile Software Development,

15、Principles, Patterns, and Practices中。,依賴倒轉(zhuǎn)原則,依賴倒轉(zhuǎn)原則分析 簡單來說,依賴倒轉(zhuǎn)原則就是指:代碼要依賴于抽象的類,而不要依賴于具體的類;要針對接口或抽象類編程,而不是針對具體類編程。 實現(xiàn)開閉原則的關(guān)鍵是抽象化,并且從抽象化導出具體化實現(xiàn),如果說開閉原則是面向?qū)ο笤O(shè)計的目標的話,那么依賴倒轉(zhuǎn)原則就是面向?qū)ο笤O(shè)計的主要手段。,依賴倒轉(zhuǎn)原則,依賴倒轉(zhuǎn)原則分析 依賴倒轉(zhuǎn)原則的常用實現(xiàn)方式之一是在代碼中使用抽象類,而將具體類放在配置文件中。 “將抽象放進代碼,將細節(jié)放進元數(shù)據(jù)” Put Abstractions in Code, Details in Me

16、tadata (程序員修煉之道:從小工到專家(The Pragmatic programmer: from journeyman to master) ),依賴倒轉(zhuǎn)原則,依賴倒轉(zhuǎn)原則分析 類之間的耦合 零耦合關(guān)系 具體耦合關(guān)系 抽象耦合關(guān)系 依賴倒轉(zhuǎn)原則要求客戶端依賴于抽象耦合,以抽象方式耦合是依賴倒轉(zhuǎn)原則的關(guān)鍵。,依賴倒轉(zhuǎn)原則,依賴倒轉(zhuǎn)原則分析 依賴注入,依賴倒轉(zhuǎn)原則,依賴倒轉(zhuǎn)原則分析 依賴注入 構(gòu)造注入(Constructor Injection):通過構(gòu)造函數(shù)注入實例變量。 設(shè)值注入(Setter Injection):通過Setter方法注入實例變量。 接口注入(Interface I

17、njection):通過接口方法注入實例變量。,依賴倒轉(zhuǎn)原則,依賴倒轉(zhuǎn)原則實例 實例說明 某系統(tǒng)提供一個數(shù)據(jù)轉(zhuǎn)換模塊,可以將來自不同數(shù)據(jù)源的數(shù)據(jù)轉(zhuǎn)換成多種格式,如可以轉(zhuǎn)換來自數(shù)據(jù)庫的數(shù)據(jù)(DatabaseSource)、也可以轉(zhuǎn)換來自文本文件的數(shù)據(jù)(TextSource),轉(zhuǎn)換后的格式可以是XML文件(XMLTransformer)、也可以是XLS文件(XLSTransformer)等。,依賴倒轉(zhuǎn)原則,依賴倒轉(zhuǎn)原則實例 實例說明 由于需求的變化,該系統(tǒng)可能需要增加新的數(shù)據(jù)源或者新的文件格式,每增加一個新的類型的數(shù)據(jù)源或者新的類型的文件格式,客戶類MainClass都需要修改源代碼,以便使用新的

18、類,但違背了開閉原則?,F(xiàn)使用依賴倒轉(zhuǎn)原則對其進行重構(gòu)。,依賴倒轉(zhuǎn)原則,依賴倒轉(zhuǎn)原則實例 實例解析,接口隔離原則,接口隔離原則定義 接口隔離原則(Interface Segregation Principle, ISP)的定義如下: 客戶端不應該依賴那些它不需要的接口。 其英文定義為: Clients should not be forced to depend upon interfaces that they do not use. 注意,在該定義中的接口指的是所定義的方法。 另一種定義方法如下: 一旦一個接口太大,則需要將它分割成一些更細小的接口,使用該接口的客戶端僅需知道與之相關(guān)的方法即

19、可。 其英文定義為: Once an interface has gotten too fat it needs to be split into smaller and more specific interfaces so that any clients of the interface will only know about the methods that pertain to them.,接口隔離原則,接口隔離原則分析 接口隔離原則是指使用多個專門的接口,而不使用單一的總接口。每一個接口應該承擔一種相對獨立的角色,不多不少,不干不該干的事,該干的事都要干。 (1) 一個接口就只代

20、表一個角色,每個角色都有它特定的一個接口,此時這個原則可以叫做“角色隔離原則”。 (2) 接口僅僅提供客戶端需要的行為,即所需的方法,客戶端不需要的行為則隱藏起來,應當為客戶端提供盡可能小的單獨的接口,而不要提供大的總接口。,接口隔離原則,接口隔離原則分析 使用接口隔離原則拆分接口時,首先必須滿足單一職責原則,將一組相關(guān)的操作定義在一個接口中,且在滿足高內(nèi)聚的前提下,接口中的方法越少越好。 可以在進行系統(tǒng)設(shè)計時采用定制服務的方式,即為不同的客戶端提供寬窄不同的接口,只提供用戶需要的行為,而隱藏用戶不需要的行為。,接口隔離原則,接口隔離原則實例 實例說明 下圖展示了一個擁有多個客戶類的系統(tǒng),在系

21、統(tǒng)中定義了一個巨大的接口(胖接口)AbstractService來服務所有的客戶類??梢允褂媒涌诟綦x原則對其進行重構(gòu)。,接口隔離原則,接口隔離原則實例 實例解析,合成復用原則,合成復用原則定義 合成復用原則(Composite Reuse Principle, CRP)又稱為組合/聚合復用原則(Composition/ Aggregate Reuse Principle, CARP),其定義如下: 盡量使用對象組合,而不是繼承來達到復用的目的。 其英文定義為: Favor composition of objects over inheritance as a reuse mechanism.

22、,合成復用原則,合成復用原則分析 合成復用原則就是指在一個新的對象里通過關(guān)聯(lián)關(guān)系(包括組合關(guān)系和聚合關(guān)系)來使用一些已有的對象,使之成為新對象的一部分;新對象通過委派調(diào)用已有對象的方法達到復用其已有功能的目的。簡言之:要盡量使用組合/聚合關(guān)系,少用繼承。,合成復用原則,合成復用原則分析 在面向?qū)ο笤O(shè)計中,可以通過兩種基本方法在不同的環(huán)境中復用已有的設(shè)計和實現(xiàn),即通過組合/聚合關(guān)系或通過繼承。 繼承復用:實現(xiàn)簡單,易于擴展。破壞系統(tǒng)的封裝性;從基類繼承而來的實現(xiàn)是靜態(tài)的,不可能在運行時發(fā)生改變,沒有足夠的靈活性;只能在有限的環(huán)境中使用。(“白箱”復用 ) 組合/聚合復用:耦合度相對較低,選擇性地

23、調(diào)用成員對象的操作;可以在運行時動態(tài)進行。(“黑箱”復用 ),合成復用原則,合成復用原則分析 組合/聚合可以使系統(tǒng)更加靈活,類與類之間的耦合度降低,一個類的變化對其他類造成的影響相對較少,因此一般首選使用組合/聚合來實現(xiàn)復用;其次才考慮繼承,在使用繼承時,需要嚴格遵循里氏代換原則,有效使用繼承會有助于對問題的理解,降低復雜度,而濫用繼承反而會增加系統(tǒng)構(gòu)建和維護的難度以及系統(tǒng)的復雜度,因此需要慎重使用繼承復用。,合成復用原則,合成復用原則實例 實例說明 某教學管理系統(tǒng)部分數(shù)據(jù)庫訪問類設(shè)計如圖所示:,合成復用原則,合成復用原則實例 實例說明 如果需要更換數(shù)據(jù)庫連接方式,如原來采用JDBC連接數(shù)據(jù)庫

24、,現(xiàn)在采用數(shù)據(jù)庫連接池連接,則需要修改DBUtil類源代碼。如果StudentDAO采用JDBC連接,但是TeacherDAO采用連接池連接,則需要增加一個新的DBUtil類,并修改StudentDAO或TeacherDAO的源代碼,使之繼承新的數(shù)據(jù)庫連接類,這將違背開閉原則,系統(tǒng)擴展性較差。 現(xiàn)使用合成復用原則對其進行重構(gòu)。,合成復用原則,合成復用原則實例 實例解析,迪米特法則,迪米特法則定義 迪米特法則(Law of Demeter, LoD)又稱為最少知識原則(Least Knowledge Principle, LKP),它有多種定義方法,其中幾種典型定義如下: (1) 不要和“陌生人

25、”說話。英文定義為:Dont talk to strangers. (2) 只與你的直接朋友通信。英文定義為:Talk only to your immediate friends. (3) 每一個軟件單位對其他的單位都只有最少的知識,而且局限于那些與本單位密切相關(guān)的軟件單位。英文定義為:Each unit should have only limited knowledge about other units: only units closely related to the current unit.,迪米特法則,迪米特法則分析 迪米特法則來自于1987年秋美國東北大學(Northeas

26、tern University)一個名為“Demeter”的研究項目。 簡單地說,迪米特法則就是指一個軟件實體應當盡可能少的與其他實體發(fā)生相互作用。這樣,當一個模塊修改時,就會盡量少的影響其他的模塊,擴展會相對容易,這是對軟件實體之間通信的限制,它要求限制軟件實體之間通信的寬度和深度。,迪米特法則,迪米特法則分析 在迪米特法則中,對于一個對象,其朋友包括以下幾類: (1) 當前對象本身(this); (2) 以參數(shù)形式傳入到當前對象方法中的對象; (3) 當前對象的成員對象; (4) 如果當前對象的成員對象是一個集合,那么集合中的元素也都是朋友; (5) 當前對象所創(chuàng)建的對象。 任何一個對象,如果滿足上面的條件之一,就是當前對象的“朋友”,否則就是“陌生人”。,迪米特法則,迪米特法則分析 迪米特法則可分為狹義法則和廣義法則。在狹義的迪米特法則中,如果兩個類之間不必彼此直接通信,那么這兩個類就不應當發(fā)生直接的相互作用,如果其中的一個類需要調(diào)用另一個類的某一個方法的話,可以通過第三者轉(zhuǎn)發(fā)這個調(diào)用。,迪米特法則,迪米特法則分析 狹義的迪米特法則:可以降低類之間的耦合,但是會在系統(tǒng)中增加大量的小方法并散落在系統(tǒng)的各個角落,它可以使一個系統(tǒng)的局部設(shè)計簡化,因為每一個局部都不會和遠距離的對象有直接的關(guān)聯(lián),但是也會造成系統(tǒng)的不同模塊之

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負責。
  • 6. 下載文件中如有侵權(quán)或不適當內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論