設(shè)計(jì)模式面向?qū)ο笤O(shè)計(jì)原則實(shí)用教案

1、大綱(dgng)w 面向?qū)ο笤O(shè)計(jì)原則概述w 單一職責(zé)原則w 開閉(ki b)原則w 里氏代換原則w 依賴倒轉(zhuǎn)原則w 接口隔離原則w 合成復(fù)用原則w 迪米特法則第1頁/共41頁第一頁，共41頁。面向?qū)ο笤O(shè)計(jì)(shj)原則概述 可維護(hù)性(Maintainability)：指軟件能夠被理解、改正、適應(yīng)及擴(kuò)展的難易程度 可復(fù)用性(Reusability)：指軟件能夠被重復(fù)使用的難易程度 面向?qū)ο笤O(shè)計(jì)的目標(biāo)之一在于支持可維護(hù)性復(fù)用，一方面需要實(shí)現(xiàn)設(shè)計(jì)方案或者源代碼的復(fù)用，另一方面要確保系統(tǒng)能夠易于擴(kuò)展和修改(xigi)，具有良好的可維護(hù)性第2頁/共41頁第二頁，共41頁。面向?qū)ο笤O(shè)計(jì)原則(yunz)概述

2、 面向?qū)ο笤O(shè)計(jì)原則為支持可維護(hù)性復(fù)用而誕生(dnshng) 指導(dǎo)性原則，非強(qiáng)制性原則 每一個設(shè)計(jì)模式都符合一個或多個面向?qū)ο笤O(shè)計(jì)原則，面向?qū)ο笤O(shè)計(jì)原則是用于評價一個設(shè)計(jì)模式的使用效果的重要指標(biāo)之一第3頁/共41頁第三頁，共41頁。面向?qū)ο笤O(shè)計(jì)原則(yunz)概述設(shè)計(jì)原則名稱設(shè)計(jì)原則名稱定定 義義使用頻率使用頻率單一職責(zé)原則單一職責(zé)原則(Single Responsibility Principle, SRP)一個對象應(yīng)該只包含單一的職責(zé)，并且該職責(zé)被一個對象應(yīng)該只包含單一的職責(zé)，并且該職責(zé)被完整地封裝在一個類完整地封裝在一個類中中開閉原則開閉原則(Open-Closed Principle,

3、OCP)軟件實(shí)體應(yīng)當(dāng)對擴(kuò)展開放，對修改軟件實(shí)體應(yīng)當(dāng)對擴(kuò)展開放，對修改關(guān)閉關(guān)閉里氏代換原則里氏代換原則(Liskov Substitution Principle, LSP)所有引用基類的地方必須能透明地使用其子類的所有引用基類的地方必須能透明地使用其子類的對象對象依賴倒轉(zhuǎn)原則依賴倒轉(zhuǎn)原則(Dependence Inversion Principle, DIP)高層模塊不應(yīng)該依賴低層模塊，它們都應(yīng)該依賴高層模塊不應(yīng)該依賴低層模塊，它們都應(yīng)該依賴抽象。抽象不應(yīng)該依賴于細(xì)節(jié)，細(xì)節(jié)應(yīng)該依賴于抽象。抽象不應(yīng)該依賴于細(xì)節(jié)，細(xì)節(jié)應(yīng)該依賴于抽象抽象接口隔離原則接口隔離原則(Interface Segregat

4、ion Principle, ISP)客戶端不應(yīng)該依賴那些它不需要的客戶端不應(yīng)該依賴那些它不需要的接口接口合成復(fù)用原則合成復(fù)用原則( C o m p o s i t e R e u s e Principle, CRP)優(yōu)先使用對象組合，而不是繼承來達(dá)到復(fù)用的優(yōu)先使用對象組合，而不是繼承來達(dá)到復(fù)用的目目的的迪米特法則迪米特法則(Law of Demeter, LoD)每一個軟件單位對其他的單位都只有最少的知識，每一個軟件單位對其他的單位都只有最少的知識，而且局限于那些與本單位密切相關(guān)的軟件而且局限于那些與本單位密切相關(guān)的軟件單位單位第4頁/共41頁第四頁，共41頁。單一職責(zé)(zhz)原則 單一

5、(dny)職責(zé)原則定義 單一(dny)職責(zé)原則是最簡單的面向?qū)ο笤O(shè)計(jì)原則，用于控制類的粒度大小單一職責(zé)原則：單一職責(zé)原則：一個對象應(yīng)該只包含單一的職責(zé)只包含單一的職責(zé)，并且該職責(zé)被完整地封裝在一個類中。Single Responsibility Principle (SRP): Every object should have a single responsibility, and that responsibility should be entirely encapsulated by the class. 第5頁/共41頁第五頁，共41頁。單一職責(zé)(zhz)原則 單一職責(zé)原則定義 就一

6、個類而言，應(yīng)該僅有一個引起(ynq)它變化的原因 There should never be more than one reason for a class to change.第6頁/共41頁第六頁，共41頁。單一職責(zé)(zhz)原則 單一職責(zé)原則分析 一個類（大到模塊，小到方法）承擔(dān)的職責(zé)越多，它被復(fù)用的可能性就越小 當(dāng)一個職責(zé)變化時，可能會影響其他職責(zé)的運(yùn)作 將這些職責(zé)進(jìn)行( jnxng)分離，將不同的職責(zé)封裝在不同的類中 將不同的變化原因封裝在不同的類中 單一職責(zé)原則是實(shí)現(xiàn)高內(nèi)聚、低耦合的指導(dǎo)方針第7頁/共41頁第七頁，共41頁。單一職責(zé)(zhz)原則 單一職責(zé)原則(yunz)實(shí)例 實(shí)

7、例說明某軟件公司開發(fā)人員針對CRM（Customer Relationship Management，客戶關(guān)系管理）系統(tǒng)中的客戶信息圖表統(tǒng)計(jì)模塊提出了如圖2-1所示的初始設(shè)計(jì)方案。圖圖2-1 初始設(shè)計(jì)方案結(jié)構(gòu)圖初始設(shè)計(jì)方案結(jié)構(gòu)圖在圖2-1中，GetConnection()方法用于連接數(shù)據(jù)庫，F(xiàn)indCustomers()用于查詢所有的客戶信息，CreateChart()用于創(chuàng)建圖表，DisplayChart()用于顯示圖表?，F(xiàn)使用單一職責(zé)原則對其進(jìn)行重構(gòu)。第8頁/共41頁第八頁，共41頁。單一職責(zé)(zhz)原則 單一職責(zé)原則(yunz)實(shí)例 實(shí)例解析 第9頁/共41頁第九頁，共41頁。開閉(k

8、i b)原則 開閉原則(yunz)定義 開閉原則(yunz)是面向?qū)ο蟮目蓮?fù)用設(shè)計(jì)的第一塊基石，是最重要的面向?qū)ο笤O(shè)計(jì)原則(yunz)開閉原則：開閉原則：軟件實(shí)體應(yīng)當(dāng)對擴(kuò)展開放，對修改關(guān)閉對擴(kuò)展開放，對修改關(guān)閉。Open-Closed Principle (OCP): Software entities should be open for extension, but closed for modification.第10頁/共41頁第十頁，共41頁。開閉(ki b)原則 開閉原則分析 開閉原則由Bertrand Meyer于1988年提出 在開閉原則的定義中，軟件實(shí)體可以是一個軟件模塊、一

9、個由多個類組成(z chn)的局部結(jié)構(gòu)或一個獨(dú)立的類 開閉原則是指軟件實(shí)體應(yīng)盡量在不修改原有代碼的情況下進(jìn)行擴(kuò)展第11頁/共41頁第十一頁，共41頁。開閉(ki b)原則 開閉原則分析 抽象化是開閉原則的關(guān)鍵 相對穩(wěn)定的抽象層 + 靈活(ln hu)的具體層 對可變性封裝原則(Principle of Encapsulation of Variation, EVP)：找到系統(tǒng)的可變因素并將其封裝起來第12頁/共41頁第十二頁，共41頁。里氏代換(di hun)原則 里氏代換原則(yunz)定義 里氏代換原則：里氏代換原則：如果對每一個類型為S的對象o1，都有類型為T的對象o2，使得以T定義的所

10、有程序P在所有的對象o1都代換o2時，程序P的行為沒有變化，那么類型S是類型T的子類型。Liskov Substitution Principle (LSP): 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 unchanged when o1 is substituted for o2 then S is a subtype of T.里氏代換原則：里氏代換原則：所有引

11、用基類基類的地方必須能透明地使用其子類子類的對象。Liskov Substitution Principle (LSP): Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.第13頁/共41頁第十三頁，共41頁。里氏代換(di hun)原則 里氏代換原則分析 里氏代換原則由2008年圖靈獎得主、美國(mi u)第一位計(jì)算機(jī)科學(xué)女博士、麻省理工學(xué)院教授Barbara Liskov和卡內(nèi)基.梅隆大學(xué)Je

12、annette Wing教授于1994年提出芭芭拉利斯科夫（Barbara Liskov），美國計(jì)算機(jī)科學(xué)家，2008年圖靈獎得主，2004年約翰.馮諾依曼獎得主，美國工程院院士，美國藝術(shù)與科學(xué)院院士，美國計(jì)算機(jī)協(xié)會(xihu)會士?，F(xiàn)任麻省理工學(xué)院電子電氣與計(jì)算機(jī)科學(xué)系教授，她是美國第一個計(jì)算機(jī)科學(xué)女博士。第14頁/共41頁第十四頁，共41頁。里氏代換(di hun)原則 里氏代換原則分析 在軟件中將一個基類對象替換成它的子類對象，程序?qū)⒉粫a(chǎn)生任何錯誤和異常，反過來則不成立(chngl)。如果一個軟件實(shí)體使用的是一個子類對象的話，那么它不一定能夠使用基類對象 在程序中盡量使用基類類型來對對

13、象進(jìn)行定義，而在運(yùn)行時再確定其子類類型我喜歡動物(dngw) 我喜歡狗 因?yàn)楣肥莿游?dngw) 第15頁/共41頁第十五頁，共41頁。依賴倒轉(zhuǎn)(dozhun)原則 依賴倒轉(zhuǎn)(dozhun)原則定義依賴倒轉(zhuǎn)原則：依賴倒轉(zhuǎn)原則：高層模塊不應(yīng)該依賴低層模塊，它們都應(yīng)該依賴抽象。抽象不應(yīng)該依賴于細(xì)節(jié)，細(xì)節(jié)應(yīng)該依賴于抽象抽象不應(yīng)該依賴于細(xì)節(jié)，細(xì)節(jié)應(yīng)該依賴于抽象。Dependency Inversion Principle (DIP): High level modules should not depend upon low level modules, both should depend upon

14、 abstractions. Abstractions should not depend upon details, details should depend upon abstractions. 第16頁/共41頁第十六頁，共41頁。依賴(yli)倒轉(zhuǎn)原則 依賴(yli)倒轉(zhuǎn)原則定義 要針對接口編程，不要針對實(shí)現(xiàn)編程 Program to an interface, not an implementation.第17頁/共41頁第十七頁，共41頁。依賴倒轉(zhuǎn)(dozhun)原則 依賴倒轉(zhuǎn)原則(yunz)分析 依賴倒轉(zhuǎn)原則(yunz)是Robert C. Martin在1996年為“C+ R

15、eporter”所寫的專欄Engineering Notebook的第三篇，后來加入到他在2002年出版的經(jīng)典著作Agile Software Development, Principles, Patterns, and Practices一書中第18頁/共41頁第十八頁，共41頁。依賴(yli)倒轉(zhuǎn)原則 依賴倒轉(zhuǎn)原則分析 在程序代碼中傳遞參數(shù)時或在關(guān)聯(lián)關(guān)系中，盡量引用層次高的抽象層類，即使用接口和抽象類進(jìn)行變量類型聲明、參數(shù)類型聲明、方法(fngf)返回類型聲明，以及數(shù)據(jù)類型的轉(zhuǎn)換等 在程序中盡量使用抽象層進(jìn)行編程，而將具體類寫在配置文件中第19頁/共41頁第十九頁，共41頁。依賴(yli)

16、倒轉(zhuǎn)原則 依賴倒轉(zhuǎn)原則分析 針對抽象層編程，將具體類的對象(duxing)通過依賴注入(Dependency Injection, DI)的方式注入到其他對象(duxing) 構(gòu)造注入 設(shè)值注入（Setter注入） 接口注入第20頁/共41頁第二十頁，共41頁。依賴(yli)倒轉(zhuǎn)原則 OCP/LSP/DIP綜合實(shí)例(shl) 實(shí)例(shl)說明某軟件公司開發(fā)人員在開發(fā)CRM系統(tǒng)時發(fā)現(xiàn)：該系統(tǒng)經(jīng)常需要將存儲在TXT或Excel文件中的客戶信息轉(zhuǎn)存到數(shù)據(jù)庫中，因此需要進(jìn)行數(shù)據(jù)格式轉(zhuǎn)換。在客戶數(shù)據(jù)操作類CustomerDAO中將調(diào)用數(shù)據(jù)格式轉(zhuǎn)換類的方法來實(shí)現(xiàn)格式轉(zhuǎn)換，初始設(shè)計(jì)方案結(jié)構(gòu)如圖2-3所示：

17、圖圖2-3 初始設(shè)計(jì)方案結(jié)構(gòu)圖初始設(shè)計(jì)方案結(jié)構(gòu)圖在編碼實(shí)現(xiàn)圖2-3所示結(jié)構(gòu)時，該軟件公司開發(fā)人員發(fā)現(xiàn)該設(shè)計(jì)方案存在一個非常嚴(yán)重的問題，由于每次轉(zhuǎn)換數(shù)據(jù)時數(shù)據(jù)來源不一定相同，因此需要經(jīng)常更換數(shù)據(jù)轉(zhuǎn)換類，例如有時候需要將TXTDataConvertor改為ExcelDataConvertor，此時，需要修改CustomerDAO的源代碼，而且在引入并使用新的數(shù)據(jù)轉(zhuǎn)換類時也不得不修改CustomerDAO的源代碼，系統(tǒng)擴(kuò)展性較差，違反了開閉原則，需要對該方案進(jìn)行重構(gòu)。第21頁/共41頁第二十一頁，共41頁。依賴(yli)倒轉(zhuǎn)原則 OCP/LSP/DIP綜合(zngh)實(shí)例 實(shí)例解析 第22頁/共41

18、頁第二十二頁，共41頁。接口隔離原則(yunz) 接口隔離原則(yunz)定義接口隔離原則：接口隔離原則：客戶端不應(yīng)該依賴那些它不需要的接口不應(yīng)該依賴那些它不需要的接口。Interface Segregation Principle (ISP): Clients should not be forced to depend upon interfaces that they do not use.第23頁/共41頁第二十三頁，共41頁。接口隔離原則(yunz) 接口隔離原則分析 當(dāng)一個接口太大時，需要將它分割成一些更細(xì)小(xxio)的接口 使用該接口的客戶端僅需知道與之相關(guān)的方法即可 每一個接

19、口應(yīng)該承擔(dān)一種相對獨(dú)立的角色，不干不該干的事，該干的事都要干第24頁/共41頁第二十四頁，共41頁。接口隔離原則(yunz) 接口隔離原則分析 “接口”定義(dngy)(1)：一個類型所提供的所有方法特征的集合。一個接口代表一個角色，每個角色都有它特定的一個接口，“角色隔離原則” “接口”定義(dngy)(2)：狹義的特定語言的接口。接口僅僅提供客戶端需要的行為，客戶端不需要的行為則隱藏起來，應(yīng)當(dāng)為客戶端提供盡可能小的單獨(dú)的接口，而不要提供大的總接口，每個接口中只包含一個客戶端所需的方法，“定制服務(wù)”第25頁/共41頁第二十五頁，共41頁。接口隔離原則(yunz) 接口隔離原則(yunz)實(shí)例

20、 實(shí)例說明 某軟件公司開發(fā)人員針對CRM系統(tǒng)的客戶數(shù)據(jù)顯示模塊設(shè)計(jì)了如圖2-5所示接口，其中方法DataRead()用于從文件中讀取數(shù)據(jù)，方法TransformToXML()用于將數(shù)據(jù)轉(zhuǎn)換成XML格式，方法CreateChart()用于創(chuàng)建圖表，方法DisplayChart()用于顯示圖表，方法CreateReport()用于創(chuàng)建文字報(bào)表，方法DisplayReport()用于顯示文字報(bào)表。圖圖2-5 初始設(shè)計(jì)方案結(jié)構(gòu)圖初始設(shè)計(jì)方案結(jié)構(gòu)圖在實(shí)際使用過程中開發(fā)人員發(fā)現(xiàn)該接口很不靈活，例如：如果一個具體的數(shù)據(jù)顯示類無須進(jìn)行數(shù)據(jù)轉(zhuǎn)換（源文件本身就是XML格式），但由于實(shí)現(xiàn)了該接口，不得不實(shí)現(xiàn)其中聲明

21、的TransformToXML()方法（至少需要提供一個空實(shí)現(xiàn)）；如果需要創(chuàng)建和顯示圖表，除了需要實(shí)現(xiàn)與圖表相關(guān)的方法外，還需要實(shí)現(xiàn)創(chuàng)建和顯示文字報(bào)表的方法，否則程序在編譯時將報(bào)錯。現(xiàn)使用接口隔離原則對其進(jìn)行重構(gòu)。第26頁/共41頁第二十六頁，共41頁。接口隔離原則(yunz) 接口隔離原則實(shí)例(shl) 實(shí)例(shl)解析 第27頁/共41頁第二十七頁，共41頁。合成(hchng)復(fù)用原則 合成復(fù)用原則定義 合成復(fù)用原則又稱為組合(zh)/聚合復(fù)用原則(Composition/ Aggregate Reuse Principle, CARP)合成復(fù)用原則：合成復(fù)用原則：優(yōu)先使用對象組合使用對

22、象組合，而不是繼承而不是繼承來達(dá)到復(fù)復(fù)用用的目的。Composite Reuse Principle (CRP)：Favor composition of objects over inheritance as a reuse mechanism.第28頁/共41頁第二十八頁，共41頁。合成(hchng)復(fù)用原則 合成復(fù)用原則分析 合成復(fù)用原則就是在一個新的對象(duxing)里通過關(guān)聯(lián)關(guān)系（包括組合關(guān)系和聚合關(guān)系）來使用一些已有的對象(duxing)，使之成為新對象(duxing)的一部分 新對象(duxing)通過委派調(diào)用已有對象(duxing)的方法達(dá)到復(fù)用功能的目的 復(fù)用時要盡量使用組

23、合/聚合關(guān)系（關(guān)聯(lián)關(guān)系），少用繼承第29頁/共41頁第二十九頁，共41頁。合成(hchng)復(fù)用原則 合成復(fù)用原則分析 繼承復(fù)用：實(shí)現(xiàn)簡單，易于擴(kuò)展。破壞系統(tǒng)的封裝性；從基類繼承而來的實(shí)現(xiàn)是靜態(tài)的，不可能在運(yùn)行時發(fā)生改變，沒有足夠的靈活性；只能在有限的環(huán)境中使用。（“白箱”復(fù)用 ） 組合/聚合復(fù)用：耦合度相對較低，有選擇性地調(diào)用成員對象的操作(cozu)；可以在運(yùn)行時動態(tài)進(jìn)行，新對象可以動態(tài)地引用與成員對象類型相同的其他對象。（“黑箱”復(fù)用 ）第30頁/共41頁第三十頁，共41頁。合成(hchng)復(fù)用原則 合成(hchng)復(fù)用原則實(shí)例 實(shí)例說明某軟件公司開發(fā)人員在初期的CRM系統(tǒng)設(shè)計(jì)中，考

24、慮到客戶數(shù)量不多，系統(tǒng)采用Access作為數(shù)據(jù)庫，與數(shù)據(jù)庫操作有關(guān)的類，例如CustomerDAO類等都需要連接數(shù)據(jù)庫，連接數(shù)據(jù)庫的方法GetConnection()封裝在DBUtil類中，由于需要重用DBUtil類的GetConnection()方法，設(shè)計(jì)人員將CustomerDAO作為DBUtil類的子類，初始設(shè)計(jì)方案結(jié)構(gòu)如圖2-7所示。圖圖2-7 初始設(shè)計(jì)方案結(jié)構(gòu)圖初始設(shè)計(jì)方案結(jié)構(gòu)圖隨著客戶數(shù)量的增加，系統(tǒng)決定升級為Oracle數(shù)據(jù)庫，因此需要增加一個新的OracleDBUtil類來連接Oracle數(shù)據(jù)庫，由于在初始設(shè)計(jì)方案中CustomerDAO和DBUtil之間是繼承關(guān)系，因此在更換

25、數(shù)據(jù)庫連接方式時需要修改CustomerDAO類的源代碼，將CustomerDAO作為OracleDBUtil的子類，這將違背開閉原則。當(dāng)然也可以直接修改DBUtil類的源代碼，這同樣也違背了開閉原則?，F(xiàn)使用合成復(fù)用原則對其進(jìn)行重構(gòu)。第31頁/共41頁第三十一頁，共41頁。合成復(fù)用(f yn)原則 合成(hchng)復(fù)用原則實(shí)例 實(shí)例解析 第32頁/共41頁第三十二頁，共41頁。迪米特法則(fz) 迪米特法則(fz)定義 迪米特法則(fz)又稱為最少知識原則(Least Knowledge Principle, LKP)迪米特法則：迪米特法則：每一個軟件單位對其他的單位都只有最少的知最少的知識

26、識，而且局限于那些與本單位密切相關(guān)的軟件單位。Law of Demeter (LoD): Each unit should have only limited knowledge about other units: only units closely related to the current unit.第33頁/共41頁第三十三頁，共41頁。迪米特法則(fz) 迪米特法則分析 迪米特法則來自于1987年美國東北大學(xué)(Northeastern University)一個名為“Demeter”的研究項(xiàng)目 迪米特法則要求一個軟件實(shí)體應(yīng)當(dāng)盡可能少地與其他實(shí)體發(fā)生(fshng)相互作用 應(yīng)用迪米

27、特法則可降低系統(tǒng)的耦合度，使類與類之間保持松散的耦合關(guān)系第34頁/共41頁第三十四頁，共41頁。迪米特法則(fz) 迪米特法則分析 不要和“陌生人”說話 (Dont talk to strangers.) 只與你的直接朋友通信 (Talk only to your immediate friends.) (1) 當(dāng)前對象本身(this) (2) 以參數(shù)形式傳入到當(dāng)前對象方法中的對象 (3) 當(dāng)前對象的成員對象 (4) 如果當(dāng)前對象的成員對象是一個集合，那么集合中的元素也都是朋友 (5) 當(dāng)前對象所創(chuàng)建的對象 任何一個對象，如果滿足上面(shng min)的條件之一，就是當(dāng)前對象的“朋友”，否則就是“陌生人” 在應(yīng)用迪米特法則時，一個對象只能與直接朋友發(fā)生交互，不要和“陌生人”發(fā)