提高面向?qū)ο笤O(shè)計復(fù)用性的設(shè)計原則

1、3/17/2024,1,提高面向?qū)ο笤O(shè)計復(fù)用性的設(shè)計原則,面向?qū)ο蟮脑O(shè)計原則,3/17/2024,2,設(shè)計目標,可擴展性(Extensibility):新功能易加入系統(tǒng)。靈活性(Flexibility):允許代碼修改平穩(wěn)發(fā)生，不會涉及很多其他模塊?？刹迦胄?Pluggability):容易將一個類換為另一個具有同樣接口的類。,3/17/2024,3,軟件復(fù)用重要性,較高的生產(chǎn)率較高的軟件質(zhì)量恰當使用復(fù)用,可改善系統(tǒng)的可維護性,3

2、/17/2024,4,使一個系統(tǒng)可在更高的層次上提供了可復(fù)用性抽象化和繼承:使概念和定義可復(fù)用多態(tài):使實現(xiàn)和應(yīng)用可復(fù)用抽象化和封裝:可保持和促進系統(tǒng)的可維護性,面向?qū)ο笤O(shè)計,3/17/2024,5,抽象層次是一個應(yīng)用系統(tǒng)作戰(zhàn)略性判斷和決定的地方，那么抽象層次就應(yīng)當是較為穩(wěn)定的，應(yīng)當是復(fù)用的重點。復(fù)用的焦點不再集中在函數(shù)和算法等具體實現(xiàn)細節(jié)上，而是集中在最重要的含有宏觀商業(yè)邏輯的抽象層次上。既然如果抽象層次的模塊相對獨立于具體層

3、次的模塊的話，那么具體層次內(nèi)部的變化就不會影響到抽象層次的結(jié)構(gòu)，所以抽象層次的復(fù)用就會較為容易。,復(fù)用,3/17/2024,6,面向?qū)ο笤O(shè)計中，可維護性復(fù)用是以設(shè)計原則和設(shè)計模式為基礎(chǔ)的。,面向?qū)ο髲?fù)用,3/17/2024,7,1.開閉原則OCP:Open-Closed Principle2.里氏替換原則LSP:Liskov Substitution Principle3.依賴倒轉(zhuǎn)原則DIP:Dependency Inversi

4、on Principle4.接口隔離原則ISP:Interface Segregation Principle5.組合復(fù)用原則CRP:Compositoin Resuse Principle6.迪米特法則LoD:Law of Demeter7.單一職責(zé)原則（SRP),面向?qū)ο笤O(shè)計原則,3/17/2024,8,軟件組成實體應(yīng)該是對擴展可擴展的，但是對修改是關(guān)閉的。( Software Entities Should Be O

5、pen For Extension， But Closed For Modification),1.開-閉原則OCP,3/17/2024,9,開放-封閉法則認為應(yīng)該試圖去設(shè)計出永遠也不需要改變的模塊。關(guān)鍵在于抽象化:可給系統(tǒng)定義一個一勞永逸，不再更改的抽象設(shè)計，此設(shè)計允許有無窮無盡的行為在實現(xiàn)層被實現(xiàn)。抽象層預(yù)見所有擴展。PC外設(shè),開-閉原則,3/17/2024,10,一個軟件系統(tǒng)的所有模塊不可能都滿足OCP，但是應(yīng)該努力最小化這些

6、不滿足OCP的模塊數(shù)量。,開-閉原則,3/17/2024,11,Public class Part{ private double basePrice; public void setPrice(double price){ basePrice = price; } public double getPrice(){ return basePrice; }},OCP例-類,3/17/2024,12,

7、Public double totalprice(Part[] parts){ double total=0.0; for (int i=0;i<parts.length;i++){ total += parts[i].getPrice(); } return total;},OCP例-某類方法,3/17/2024,13,內(nèi)存折扣？,思考,3/17/2024,14,Public double total

8、price(Part[] parts){ double total=0.0; for (int i=0;i<parts.length;i++){ if(parts[I] instanceof Memory) total += parts[i].getPrice() * 0.9; else total += parts[i].getPrice(); } return t

9、otal;},方法,3/17/2024,15,符合OCP嗎？,思考,3/17/2024,16,Public class Memory extends Part{ public double getPrice(){ return basePrice * 0.9; }},方法？,3/17/2024,17,采用一個PricePolicy類，通過對其進行繼承以提供不同的計價策略,更好的方法？,3/17/2024,18,Pub

10、lic class Part{ private PricePolicy pricePolicy; public void setPricePolicy(PricePolicy policy){ pricePolicy = policy; } public void setPrice(double price){ pricePolicy.setPrice( price ); } public dou

11、ble getPrice(){ return pricePolicy.getPrice(); }},方法,3/17/2024,19,Public class PricePolicy{ private double basePrice; public void setPrice(double price){ basePrice = price; } public double getPrice(){

12、 return basePrice; }},價格策略,3/17/2024,20,Public class Sale extends PricePolicy{ private double discount; public void setDiscount(double discount){ this.discount = discount; } public double getPrice(){

13、 return basePrice * discount; }},銷售策略,3/17/2024,21,符合OCP了嗎？,思考,3/17/2024,22,應(yīng)用實例,我們有一個需要在標準的GUI上繪制園和正方形的應(yīng)用程序。圓和正方形必須要按照特定的順序繪制。我們將創(chuàng)建一個列表，列表由按照適當?shù)捻樞蚺帕械膱@和正方形組成，程序遍歷該列表，一次繪制出每個圓和正方形。,3/17/2024,23,,先考慮違反OCP的過程化方法定義一個Dra

14、wAllShapes函數(shù)使用SWITCH來分支繪制圖形為什么不符合OCP？因為它對于新的形狀類型的添加不是封閉的每增加一種新的形狀類型，都必須要更改這個函數(shù),3/17/2024,24,,這樣的設(shè)計糟糕在哪里？增加形狀會導(dǎo)致所有的程序、變量重新編譯和部署想在另一個程序中復(fù)用DrawAllShape這個函數(shù)時，都必須要附帶上Square和Circle，即時那個程序不需要它們。,3/17/2024,25,怎樣遵循OCP,編寫一個sh

15、ape抽象類這個類僅有一個抽象方法draw()所有形狀都從這個類派生當繪制一種新的形狀，只需要增加一個新的shape類的派生類。而DrawAllShapes 函數(shù)并不需要改變。,3/17/2024,26,使用指向基類(超類)的引用的函數(shù)，必須能夠在不知道具體派生類(子類)對象類型的情況下使用它們。(Function Thar Use Referennces To Base(Super) Classes Must Be Able T

16、o Use Objects Of Derived(Sub) Classes Without Knowing It),2.里氏替換法則,3/17/2024,27,Public class Rectangle{ private double width; private double heigth; public Rectangle(double w,double h) { width = w; heigth = h;

17、 } public void setWidth(double w){ width = w; } public void setHeigth(double h){ height = h; } public double getWidth(){ return width; } public double getHeigth(){ return height; } public double area(){ re

18、turn width * height; }},LSP例-矩形類,3/17/2024,28,正方形類 Square正方形是矩形，因此Square類應(yīng)該從Rectangle類派生而來。,思考,3/17/2024,29,Public class Square extends Rectangle{ public Square(double s) { super(s,s); } public void setWidth(

19、double w){ super.setWidth ( w ); super.setHeight( w ); } public void setHeight(double h){ super.setWidth ( h ); super.setHeight( h ); }},正方形類,3/17/2024,30,Public class TestRectangle{ public

20、static void testLSP(Rectangle r) { r.setWidth(4.0); r.setHeight(5.0); System.out.println(“Width is 4.0 and Height is 5.0 ,Area is ” + r.area()); },測試類,3/17/2024,31,public static void main(String args[]){

21、 Rectangle r=new Rectangle(1.0,1.0); Square s = new Square(1.0); testLSP ( r ); testLSP ( s ); }},測試,3/17/2024,32,編寫testLsp()方法的程序員做了一個合理的假設(shè)，即改變Rectangle的寬而保持它的高不變。一個數(shù)學(xué)意義上的正方形可能是一個矩形，但是一個Square對象不是一個Rectangle

22、對象，因為一個Square對象的行為與一個Rectangle對象的行為是不一致的！(矩形 僅包含get 因為set不同)從行為上來說，一個Square不是一個Rectangle！一個Square對象與一個Rectangle對象之間不具有多態(tài)的特征。,問題,3/17/2024,33,Liskov替換法則(LSP)清楚地表明了ISA關(guān)系全部都是與行為有關(guān)的。為了保持LSP，所有子類必須符合使用基類的client所期望的行為。一個子類型

23、不得具有比基類型更多的限制，可能這對于基類型來說是合法的，但是可能會因為違背子類型的其中一個額外限制，從而違背了LSP！LSP保證一個子類總是能夠被用在其基類可以出現(xiàn)的地方,小結(jié),3/17/2024,34,抽象不應(yīng)當依賴于細節(jié)，細節(jié)應(yīng)當依賴于抽象。(Abstations should not depend upon details， Details should depend upon abstractions),3.依賴倒轉(zhuǎn)原則,

24、3/17/2024,35,針對接口編程，而非實現(xiàn)Program To An Interface， Not An Implementation,DIP,3/17/2024,36,Client不必知道其使用對象的具體所屬類。一個對象可以很容易地被(實現(xiàn)了相同接口的)的另一個對象所替換。對象間的連接不必硬綁定(hardwire)到一個具體類的對象上，因此增加了靈活性。松散藕合(loosens coupling)。增加了重用的可能性。

25、提高了(對象)組合的機率，因為被包含對象可以是任何實現(xiàn)了一個指定接口的類。,使用接口的優(yōu)點,3/17/2024,37,不將變量聲明為某個特定的具體類的實例對象，而讓其遵從抽象類定義的接口。實現(xiàn)類僅實現(xiàn)接口，不添加方法。(Draw(shape*p) 不要Cricle*p Rectangle *p Triangle *p),針對接口編程,3/17/2024,38,任何變量都不應(yīng)該持有一個指向具體類的指針或引用任何類都不應(yīng)該從具體

26、類派生任何方法都不應(yīng)該覆寫它的任何基類中已實現(xiàn)了的方法,依賴于抽象,3/17/2024,39,如果一個類的實例必須使用另一個對象，而這個對象又屬于一個特定的類，那么復(fù)用性會受到損害。如果“使用”類只需使用“被使用”類的某些方法，而不是要求“被使用”類與“使用”類有“is-a”的關(guān)系，就可考慮，讓“被使用”類實現(xiàn)一個接口，“使用”類通過這個接口來使用需要的方法，從而限制了類之間的依賴。方案:為避免類之間因彼此使用而造成的耦合，讓它們

27、通過接口間接使用。,約束,3/17/2024,40,DIP可應(yīng)用于任何存在一個類向另一個類發(fā)送消息的地方。,DIP應(yīng)用,3/17/2024,41,例,3/17/2024,42,例-找出潛在的抽象,3/17/2024,43,,實例考慮一個控制熔爐調(diào)節(jié)器的軟件，該軟件可以從一個IO通道中讀取當前的溫度，并通過向另一個IO通道發(fā)送命令來指示熔爐的開或者關(guān)。,3/17/2024,44,優(yōu)先使用(對象)組合，而非(類)繼承Favor Comp

28、osition Over Inheritance,4.組合復(fù)用原則,3/17/2024,45,容器類僅能通過被包含對象的接口來對其進行訪問?！昂诤小睆?fù)用，因為被包含對象的內(nèi)部細節(jié)對外是不可見。封裝性好。實現(xiàn)上的相互依賴性比較小。每一個類只專注于一項任務(wù)。通過獲取指向其它的具有相同類型的對象引用，可以在運行期間動態(tài)地定義(對象的)組合。,組合優(yōu)點,3/17/2024,46,從而導(dǎo)致系統(tǒng)中的對象過多。為了能將多個不同的對象作為組

29、合塊(composition block)來使用，必須仔細地對接口進行定義。,組合缺點,3/17/2024,47,(類)繼承是一種通過擴展一個已有對象的實現(xiàn)，從而獲得新功能的復(fù)用方法。泛化類(超類)可以顯式地捕獲那些公共的屬性和方法。特殊類(子類)則通過附加屬性和方法來進行實現(xiàn)的擴展,繼承,3/17/2024,48,容易進行新的實現(xiàn)，因為其大多數(shù)可繼承而來。易于修改或擴展那些被復(fù)用的實現(xiàn)。,繼承優(yōu)點,3/17/2024,49,破壞

30、了封裝性，因為這會將父類的實現(xiàn)細節(jié)暴露給子類?！鞍缀小睆?fù)用，因為父類的內(nèi)部細節(jié)對于子類而言通常是可見的。當父類的實現(xiàn)更改時，子類也不得不會隨之更改。從父類繼承來的實現(xiàn)將不能在運行期間進行改變。,繼承缺點,3/17/2024,50,僅當下列的所有標準被滿足時，方可使用繼承：子類表達了“是一個…的特殊類型”，而非“是一個由…所扮演的角色”。子類的一個實例永遠不需要轉(zhuǎn)化(transmute)為其它類的一個對象。子類是對其父類的職責(zé)

31、(responsibility)進行擴展，而非重寫或廢除(nullify)。子類沒有對那些僅作為一個工具類(utility class)的功能進行擴展。,Coad規(guī)則,3/17/2024,51,例,3/17/2024,52,組合與繼承都是重要的重用方法在OO開發(fā)的早期，繼承被過度地使用隨著時間的發(fā)展，我們發(fā)現(xiàn)優(yōu)先使用組合可以獲得重用性與簡單性更佳的設(shè)計當然可以通過繼承，以擴充可用的組合類集。因此組合與繼承可以一起工作但是我們

32、的基本法則是：優(yōu)先使用對象組合，而非(類)繼承,小結(jié),3/17/2024,53,Law of Demeter又稱 最少知識原則，一個對象應(yīng)該對其他對象盡可能少的了解。,5.迪米特法則 (LoD),3/17/2024,54,控制信息過載，提高封裝能力。1.創(chuàng)建弱耦合類，利于復(fù)用2.降低成員訪問權(quán)限3.設(shè)計不變類,廣義,3/17/2024,55,如果兩個類不必彼此通信，那么這兩個類就不應(yīng)當發(fā)生直接的相互作用。如果其中的一個類需

33、要調(diào)用另一個類的某一個方法的話，可通過第三者轉(zhuǎn)發(fā)這個調(diào)用。,狹義,3/17/2024,56,Void Someone::Operation1(Friend friend){ Stranger stranger = friend.provide(); stranger.Operation3();}Stranger Friend::provide(){ return stranger;},例,3/17/2024,57,滿

34、足LOD嗎？,思考,3/17/2024,58,使用多個專門的接口比使用單一的總接口好。一個類對另一個類的依賴性應(yīng)建立在最小的接口上。,6.接口隔離原則 (ISP),3/17/2024,59,定制服務(wù):為同一角色提供寬窄不同的接口。(承諾多，維護難),ISP,3/17/2024,60,,如果類的接口不是內(nèi)聚的，就表示該類具有“胖”的接口。ISP建議客戶程序不應(yīng)該看到它們作為單一的類存在。客戶程序看到的應(yīng)該是多個具有內(nèi)聚接口的抽象基類

35、。,3/17/2024,61,,現(xiàn)在，考慮自動取款機（ATM)ATM需要一個非常靈活的用戶界面。它的輸出信息需要被轉(zhuǎn)換成許多不同的語言。輸出信息可能被顯示在屏幕上，或者通過語音器說出來。顯然界面需要創(chuàng)建一個抽象基類同樣可以把每個ATM可以執(zhí)行的操作封裝為類Transaction的派生類。有DepositTransaction,WithdrawTransaction以及TransferTransaction,每個類都調(diào)用UI的方法。