1、面向?qū)ο笤O(shè)計(jì)六大原則面向?qū)ο笤O(shè)計(jì)的原則是面向?qū)ο笏枷氲奶釤挘让嫦驅(qū)ο笏枷氲暮诵囊馗?具可操作性，但與設(shè)計(jì)模式相比，卻又更加的抽象，是設(shè)計(jì)精神要義的抽象概括。 形象地將，面向?qū)ο笏枷胂穹ɡ淼木?，設(shè)計(jì)原則則相對于基本憲法，而設(shè)計(jì)模式 就好比各式各樣的具體法律條文了。面向?qū)ο笤O(shè)計(jì)原則有6個(gè)：開放封閉原則，單一職責(zé)原則，依賴倒置原則， Liskov替換原則，迪米特法則和合成/聚合復(fù)用原則。單一職責(zé)原貝U （Single Responsibility Principle SRP There should never be more than one reason for a class to c

2、hanges么意思呢？ 所謂單一職責(zé)原則就是一個(gè)類只 負(fù)責(zé)一個(gè)職責(zé)，只有一個(gè)引起變化的原因。如果一個(gè)類承擔(dān)的職責(zé)過多，就等于把這些職責(zé)耦合在一起，一個(gè)職責(zé)的變化 會削弱或抑制這個(gè)類完成其他職責(zé)的能力，這個(gè)耦合會導(dǎo)致脆弱的設(shè)計(jì)。軟件設(shè)計(jì)真正要做的許多內(nèi)容，就是發(fā)現(xiàn)職責(zé)并把這些職責(zé)相互分離；如果能 夠想到多于一個(gè)動機(jī)去改變一個(gè)類，那么這個(gè)類就具有多于一個(gè)職責(zé)，就應(yīng)該考慮 類的分離。以調(diào)制解調(diào)器為例如下圖：從上述類圖里面我們發(fā)現(xiàn)有四個(gè)方法 Dial（撥通電話,Hangupe電話, Receive畋到信息，Send儂送信息，經(jīng)過分析不難判斷出，實(shí)際上 Dial（撥通電話 和Hangup（掛電話是屬于連

3、接的范疇，而 Receive畋到信息和Send發(fā)送信息 是屬 于數(shù)據(jù)傳送的范疇。這里類包括兩個(gè)職責(zé)，顯然違反了SRP。這樣做有潛在的隱患，如果要改變連接的方式，勢必要修改Modem ,而修改Modem類的結(jié)果導(dǎo)致凡事依賴 Modem類可能都需要修改，這樣就需要重新編譯和 部署，不管數(shù)據(jù)傳輸這部分是否需要修改。因此要重構(gòu)Modem類，從中抽象出兩個(gè)接口，一個(gè)專門負(fù)責(zé)連接，另一個(gè)專 門負(fù)責(zé)數(shù)據(jù)傳送。依賴 Modem類的元素要做相應(yīng)的細(xì)化，根據(jù)職責(zé)的不同分別依 賴不同的接口。如下圖：這樣以來，無論單獨(dú)修改連接部分還是單獨(dú)修改數(shù)據(jù)傳送部分，都彼此互不影 響?？偨Y(jié)單一職責(zé)優(yōu)點(diǎn)：降低類的復(fù)雜性，提高可維護(hù)

4、性提高可讀性。降低需求變化帶來的風(fēng)險(xiǎn)。需求變化是不可避免的，如果單一職責(zé)做的好，一 個(gè)接口修改只對相應(yīng)的實(shí)現(xiàn)類有影響，對其它的接口無影響，這對系統(tǒng)的擴(kuò)展性和 維護(hù)性都有很大的幫助。開放封閉原則(Open-Closed Principle OCPSoftware entities(classes,modules,functions etc should open for extension ,but close for modification.什么意思呢？所謂開放封閉原則就是軟件實(shí)體應(yīng)該對擴(kuò)展開發(fā)，而對修改封閉。開放封閉原 則是所有面向?qū)ο笤瓌t的核心。軟件設(shè)計(jì)本身所追求的目標(biāo)就是封裝變化，降低

5、耦 合，而開放封閉原則正是對這一目標(biāo)的最直接體現(xiàn)。開放封閉原則主要體現(xiàn)在兩個(gè)方面：對擴(kuò)展開放，意味著有新的需求或變化時(shí)，可以對現(xiàn)有代碼進(jìn)行擴(kuò)展，以適應(yīng) 新的情況。對修改封閉，意味著類一旦設(shè)計(jì)完成，就可以獨(dú)立其工作，而不要對 類盡任何修改。為什么要用到開放封閉原則呢？軟件需求總是變化的，世界上沒有一個(gè)軟件的是不變的，因此對軟件設(shè)計(jì)人員 來說，必須在不需要對原有系統(tǒng)進(jìn)行修改的情況下，實(shí)現(xiàn)靈活的系統(tǒng)擴(kuò)展。如何做到對擴(kuò)展開放，對修改封閉呢？實(shí)現(xiàn)開放封閉的核心思想就是對抽象編程，而不對具體編程，因?yàn)槌橄笙鄬Ψ€(wěn) 定。讓類依賴于固定的抽象，所以對修改就是封閉的；而通過面向?qū)ο蟮睦^承和多 態(tài)機(jī)制，可以實(shí)現(xiàn)對抽

6、象體的繼承，通過覆寫其方法來改變固有行為，實(shí)現(xiàn)新的擴(kuò) 展方法，所以對于擴(kuò)展就是開放的。對于違反這一原則的類，必須通過重構(gòu)來進(jìn)行改善。常用于實(shí)現(xiàn)的設(shè)計(jì)模式主 要有Template Method模式和Strategy模式。而封裝變化，是實(shí)現(xiàn)這一原則的重要 手段，將經(jīng)常變化的狀態(tài)封裝為一個(gè)類。以銀行業(yè)務(wù)員為例沒有實(shí)現(xiàn)OCP的設(shè)計(jì)：public class BankProcess(/存款public void Deposite()/取款public void Withdraw()/轉(zhuǎn)賬public void Transfer()public class BankStaff(private BankPr

7、ocess bankpro = new BankProcess (;public void BankHandle(Client client(switch (client.Type(/存款case deposite:bankpro.Deposite(;break ;/取款case withdraw:bankpro.Withdraw(;break ;/轉(zhuǎn)賬case transfer:bankpro.Transfer(;break ;這種設(shè)計(jì)顯然是存在問題的，目前設(shè)計(jì)中就只有存款，取款和轉(zhuǎn)賬三個(gè)功能， 將來如果業(yè)務(wù)增加了，比如增加申購基金功能，理財(cái)功能等，就必須要修改 BankProcesslk務(wù)

8、類。我們分析上述設(shè)計(jì)就不能發(fā)現(xiàn)把不能業(yè)務(wù)封裝在一個(gè)類里 面，違反單一職責(zé)原則，而有新的需求發(fā)生，必須修改現(xiàn)有代碼則違反了開放封閉 原則。從開放封閉的角度來分析，在銀行系統(tǒng)中最可能擴(kuò)展的就是業(yè)務(wù)功能的增加或 變更。對業(yè)務(wù)流程應(yīng)該作為擴(kuò)展的部分來實(shí)現(xiàn)。當(dāng)有新的功能時(shí)，不需要再對現(xiàn)有 業(yè)務(wù)進(jìn)行重新梳理，然后再對系統(tǒng)做大的修改。如何才能實(shí)現(xiàn)耦合度和靈活性兼得呢？那就是抽象，將業(yè)務(wù)功能抽象為接口，當(dāng)業(yè)務(wù)員依賴于固定的抽象時(shí)，對修改 就是封閉的，而通過繼承和多態(tài)繼承，從抽象體中擴(kuò)展出新的實(shí)現(xiàn)，就是對擴(kuò)展的 開放。以下是符合OCP的設(shè)計(jì)：首先聲明一個(gè)業(yè)務(wù)處理接口public interface IBankP

9、rocess(void Process(;)public class DepositProcess : IBankProcess(public void Process(/辦理存款業(yè)務(wù)Console .WriteLine(Process Deposit;)public class WithDrawProcess : IBankProcess(public void Process(/辦理取款業(yè)務(wù)Console .WriteLine(Process WithDraw;)public class TransferProcess : IBankProcess(public void Process(

10、/辦理轉(zhuǎn)賬業(yè)務(wù)Console .WriteLine(Process Transfer;)public class BankStaffprivate IBankProcess bankpro = null ;public void BankHandle(Client client(switch (client.Type(/存款case Deposit:userProc = new DepositUser (;break ;/轉(zhuǎn)賬case Transfer:userProc = new TransferUser (;break ;/取款case WithDraw:userProc = new Wi

11、thDrawUser (;break ;userProc.Process(;)這樣當(dāng)業(yè)務(wù)變更時(shí)，只需要修改對應(yīng)的業(yè)務(wù)實(shí)現(xiàn)類就可以，其他不相干的業(yè)務(wù) 就不必修改。當(dāng)業(yè)務(wù)增加，只需要增加業(yè)務(wù)的實(shí)現(xiàn)就可以了。設(shè)計(jì)建議：開放封閉原則，是最為重要的設(shè)計(jì)原則，Liskov替換原則和合成/聚合復(fù)用原則為開放封閉原則提供保證?？梢酝ㄟ^Template Method模式和Strategy模式進(jìn)行重構(gòu)，實(shí)現(xiàn)對修改封閉， 對擴(kuò)展開放的設(shè)計(jì)思路。封裝變化，是實(shí)現(xiàn)開放封閉原則的重要手段，對于經(jīng)常發(fā)生變化的狀態(tài)，一般 將其封裝為一個(gè)抽象，例如銀行業(yè)務(wù)中舊ankProcess接口。拒絕濫用抽象，只將經(jīng)常變化的部分進(jìn)行抽象。

12、里氏替換原則(Liskov Substitution Principle LSP)里氏替換原則是面向?qū)ο笤O(shè)計(jì)的基本原則之一。任何基類可以出現(xiàn)的地方，子 類一定可以出現(xiàn)。LSP是繼承復(fù)用的基石，只有當(dāng)子類可以替換基類，軟件單位的 功能不受影響時(shí)，基類才能真正的被復(fù)用，而子類也可以在基類的基礎(chǔ)上增加新的 行為。Liskov 提出了 關(guān)于繼承的原貝: Inheritance should ensure that any property proved about supertype objects also holds for subtype objects.-繼承必須確保超類中 所擁有的性質(zhì)在子類

13、中仍然成立。2002年，軟件工程大師 Robert C. Martin出版了一本AgileSoftware DevelopmentPrinciples Patterns and Practices,在文中他把里氏代換原則最終簡化為一句話：“Subtypes must be substitutable for their base typ般就是說子 ”類必須能夠替換成他們的基類。里氏替換原則講的是基類和子類的關(guān)系，只有這種關(guān)系存在的時(shí)候里氏替換原 則才能成立。里氏替換原則是實(shí)現(xiàn)開放封閉原則的具體規(guī)范。這是因?yàn)椋簩?shí)現(xiàn)開放 封閉原則的關(guān)鍵是抽象，而繼承關(guān)系又是抽象的一種具體實(shí)現(xiàn)。我們大家都打過CS的

14、游戲，用槍射擊殺人，如下類圖：槍的主要職責(zé)是射擊，如何射擊在各個(gè)具體的子類中定義。注意在類中調(diào)用其 他類時(shí)務(wù)必調(diào)用父類或接口，如果不能掉話父類或接口，說明類的射擊已經(jīng)違反了 LSP原則。如果我們有一個(gè)玩具手 槍，該如何定義呢？我們先在類圖 2-1上增加一個(gè)類ToyGun ,然后繼承于AbstractGun類，修改后的類圖如下:玩具槍是不能用來射擊的，殺不死人的，這個(gè)不應(yīng)該寫 shoot方法，在這種情 況下業(yè)務(wù)的調(diào)用類就會出現(xiàn)問題。為了解決這個(gè)問題， ToyGun可以脫離繼承，建 立一個(gè)獨(dú)立的父類，為了做到代碼可以服用，可以與 AbstractGun建立關(guān)聯(lián)委托關(guān) 系，如下圖：因此，如果子類不能

15、完整地實(shí)現(xiàn)父類的方法，那么建議斷開父子繼承關(guān)系，采 用依賴，聚合，組合等關(guān)系代替繼承。子類可以有自己的屬性或方法。覆蓋或?qū)崿F(xiàn)父類的方法時(shí)輸入的參數(shù)可以放大。覆蓋或?qū)崿F(xiàn)父類的方法時(shí)輸出結(jié)果可以被縮小。這是什么意思呢，父類的方法 返回值是一個(gè)類型T ,子類相同的方法(覆寫)的返回值為類型 S ,那么根據(jù)里 氏替換原則就要求S必須小于等于T ,也就是說要么S和T是同一個(gè)類型，要么 S是T的子類型。采用里氏替換原則的目的就是增加程序的健壯性，需求變更時(shí)也可以保持良好 的兼容性和穩(wěn)定性，即使增加子類，原有的子類可以繼續(xù)運(yùn)行。在實(shí)際項(xiàng)目中，每 個(gè)子類對應(yīng)不同的業(yè)務(wù)含義，使用父類作為參數(shù)，傳遞不同的子類完成

16、不同業(yè)務(wù)邏 輯。4依賴倒置原則所謂依賴倒置原則(Dependence Inversion Principles)就是要依賴于抽象，不 要依賴于具體。簡單的說就是對抽象進(jìn)行編程，不要對實(shí)現(xiàn)進(jìn)行編程，這樣就降低 了客戶與實(shí)現(xiàn)模塊間的耦合。面向過程的開發(fā)，上層調(diào)用下層，上層依賴于下層，當(dāng)下層劇烈變化時(shí)，上層 也要跟著變化，這就會導(dǎo)致模塊的復(fù)用性降低而且大大提高了開發(fā)的成本。面向?qū)ο蟮拈_發(fā)很好的解決了這個(gè)問題，一般的情況下抽象的變化概率很小， 讓用戶程序依賴于抽象，實(shí)現(xiàn)的細(xì)節(jié)也依賴于抽象。即使實(shí)現(xiàn)細(xì)節(jié)不斷變化，只要 抽象不變，客戶程序就不需要變化。這大大降低了客戶程序域?qū)崿F(xiàn)細(xì)節(jié)的耦合度。比如一個(gè)合資汽

17、車公司現(xiàn)在要求開發(fā)一個(gè)自動駕駛系統(tǒng)，只要汽車上安裝上這 個(gè)系統(tǒng)，就可以實(shí)現(xiàn)無人駕駛，該系統(tǒng)可以在福特車系列和本田車系列上使用。面 向過程的結(jié)構(gòu)圖：實(shí)現(xiàn)代碼如下：public class HondaCar(public void Run( Console .WriteLine(本田車啟動了! ; public void Turn( Console .WriteLine(本田車拐彎了 ！ ; public void Stop( Console .WriteLine(本田車停止了! ; public class FordCarpublic void Run( Console .WriteLine(福

18、特車啟動了 ！ ; public void Turn( Console .WriteLine(福特車拐彎了 ！ ; public void Stop( Console .WriteLine(福特車停止了 ！ ; public class AutoSystempublic enum CarType Ford,Fondaprivate HondaCar hondcar=new HondaCar (;private FordCar fordcar=new FordCar (;private CarType type;public AutoSystem(CarType carTypethis .typ

19、e = carType;public void RunCar(if (this .type = CarType .Fondahondcar.Run(;)else if (this .type = CarType .Ford(fordcar.Run(;)public void StopCar(if (this .type = CarType .Fonda(hondcar.Stop(;)else if (this .type = CarType .Ford(fordcar.Stop(;)public void TurnCar(if (this .type = CarType .Fonda(hond

20、car.Turn(;)else if (this .type = CarType .Ford(fordcar.Turn(;)顯然這個(gè)實(shí)現(xiàn)代碼也可滿足現(xiàn)在的需求。但是如何現(xiàn)在公司業(yè)務(wù)規(guī)模擴(kuò)大了，該自動駕駛系統(tǒng)還要把吉普車也兼容了 這些就需要修改 AutoSystem類如下：public class AutoSystempublic enum CarType Ford,Fonda,Jeepprivate HondaCar hondcar=new HondaCar (;private FordCar fordcar=new FordCar (;private Jeep jeep = new Jeep

21、 (;private CarType type;public AutoSystem(CarType carTypethis .type = carType;public void RunCar(if (this .type = CarType .Fonda hondcar.Run(;else if (this .type = CarType .Ford fordcar.Run(;else if (this .type = CarType .Jeep jeep.Run(;)public void StopCar(if (this .type = CarType .Fonda hondcar.St

22、op(;)else if (this .type = CarType .Ford fordcar.Stop(;)else if (this .type = CarType .Jeep jeep.Stop(;)public void TurnCar(if (this .type = CarType .Fonda hondcar.Turn(;else if (this .type = CarType .Ford fordcar.Turn(;)else if (this .type = CarType .Jeep jeep.Turn(;)通過代碼分析得知，上述代碼也確實(shí)滿足了需求，但是軟件是不斷變化

23、的，軟 件的需求也是變化的，如果將來業(yè)務(wù)又?jǐn)U大了，該自動駕駛系統(tǒng)還有能實(shí)現(xiàn)通用、 三菱、大眾汽車，這樣我們不得不又要修改AutoSystem類了。這樣會導(dǎo)致系統(tǒng)越來越臃月中，越來越大，而且依賴越來越多低層模塊，只有低層模塊變動， AutoSystem類就不得不跟著變動，導(dǎo)致系統(tǒng)設(shè)計(jì)變得非常脆弱和僵硬。導(dǎo)致上面所述問題一個(gè)原因是，含有高層策略的模塊，如 AutoSystem模塊， 依賴于它所控制的低層的具體細(xì)節(jié)的模塊(如FordCar和HondaCar)。如果能使AutoSystem模塊獨(dú)立于它所控制的具體細(xì)節(jié)，而是依賴抽象，那么我們就可以服 用它了。這就是面向?qū)ο笾械囊蕾嚨怪谩睓C(jī)制。如下類圖：

24、實(shí)現(xiàn)代碼如下：public interface ICarvoid Run(;void Stop(;void Turn(;)public class HondaCar :ICar(public void Run( Console .WriteLine(本田車啟動了! ; public void Turn( Console .WriteLine(本田車拐彎了 ！ ; public void Stop( Console .WriteLine(本田車停止了! ; public class FordCar :ICarpublic void Run( Console .WriteLine(福特車啟動了 ！

25、 ; public void Turn( Console .WriteLine(福特車拐彎了! ; public void Stop( Console .WriteLine(福特車停止了! ; public class Jeep :ICarpublic void Run( Console .WriteLine(福特車啟動了! ; public void Turn( Console .WriteLine(福特車拐彎了! ; public void Stop( Console .WriteLine(福特車停止了! ; )public class AutoSystemprivate ICar car

26、;public AutoSystem(ICar carthis .car = car;public void RunCar(this .car.Run(;public void StopCar(this .car.Stop(;public void TurnCar(this .car.Turn(;)現(xiàn)在Autosystem系統(tǒng)依賴于ICar這個(gè)抽象，而與具體的實(shí)現(xiàn)細(xì)節(jié) HondaCar : 和FordCar無關(guān)，所以實(shí)現(xiàn)細(xì)節(jié)的變化不會影響 AutoSystem.對于實(shí)現(xiàn)細(xì)節(jié)只要實(shí) 現(xiàn)ICar即可。即實(shí)現(xiàn)細(xì)節(jié)依賴于ICar抽象。綜上所述：一個(gè)應(yīng)用中的重要策略決定及業(yè)務(wù)正是在這些高層的模塊中。也正

27、是這些模塊包含這應(yīng)用的特性。但是，當(dāng)這些模塊依賴于低層模塊時(shí)，低層模塊 的修改比較將直接影響到他們，迫使它們也改變。這種情況是荒謬的。應(yīng)該是處于高層的模塊去迫使那些低層的模塊發(fā)生改變。處于高層的模塊應(yīng)優(yōu) 先于低層的模塊。無論如何高層模塊也不應(yīng)該依賴于低層模塊。而且我們想能夠復(fù) 用的是高層的模塊，只有高層模塊獨(dú)立于低層模塊時(shí)，復(fù)用才有可能?？傊?，高層次的模塊不應(yīng)該依賴于低層次的模塊，它們都應(yīng)該依賴于抽象。抽象不應(yīng)該依賴 于具體，具體應(yīng)該依賴于抽象。5迪米特法則迪米特法貝U ( Law of Demeter)又叫最少知識原則(Least Knowledge Principle LKP),就是說一個(gè)

28、對象應(yīng)當(dāng)對其他對象有盡可能少的了解，不和陌生人說話。對面向?qū)ο髞碚f，一個(gè)軟件實(shí)體應(yīng)當(dāng)盡可能的少的與其他實(shí)體發(fā)生相互作用。 每一個(gè)軟件單位對其他的單位都只有最少的知識，而其局限于那些與本單位密切相 關(guān)的軟件單位。迪米特法則的目的在于降低類之間的耦合。由于每個(gè)類盡量減少對其他類的依 賴，因此，很容易使得系統(tǒng)的功能模塊相互獨(dú)立，相互之間不存在依賴關(guān)系。應(yīng)用 迪米特法則有可能造成的一個(gè)后果就是，系統(tǒng)中存在的大量的中介類，這些類只所以存在完全是為了傳遞類之間的相互調(diào)用關(guān)系-這在一定程度上增加系統(tǒng)的復(fù)雜度。設(shè)計(jì)模式中的門面模式(Facade)和中介模式(Mediator )都是迪米特法則的 應(yīng)用的例子。狹義的迪米特法則的缺點(diǎn)：在系統(tǒng)里面造出大量的小方法，這些方法僅僅是傳遞間接的調(diào)用，與系統(tǒng)的商 業(yè)邏輯無關(guān)。遵循類之間的迪米特法則會使一個(gè)系統(tǒng)的局部設(shè)計(jì)簡化，因?yàn)槊恳粋€(gè)局部都不 會和遠(yuǎn)距離的對象有之間的關(guān)聯(lián)。但是，這也會造成系統(tǒng)