一些軟件設(shè)計(jì)原則

1、Dont Repeat Yourself (DRYDRY 是一個(gè)最簡(jiǎn)單的法則,也是最容易被理解的。但它也可能是最難被應(yīng)用的(因?yàn)橐龅竭@樣,我們需要在泛型設(shè)計(jì)上做相當(dāng)?shù)呐?這并不是一件容易的事。它意味著,當(dāng)我們?cè)趦蓚€(gè)或多個(gè)地方的時(shí)候發(fā)現(xiàn)一些相似的代碼的時(shí)候,我們需要把他們的共性抽象出來(lái)形一個(gè)唯一的新方法,并且改變現(xiàn)有的地方的代碼讓他們以一些合適的參數(shù)調(diào)用這個(gè)新的方法。Keep It Simple, Stupid (KISSKISS原則在設(shè)計(jì)上可能最被推崇的,在家裝設(shè)計(jì),界面設(shè)計(jì),操作設(shè)計(jì)上,復(fù)雜的東西越來(lái)越被眾人所BS了,而簡(jiǎn)單的東西越來(lái)越被人所認(rèn)可,比如這些UI 的設(shè)計(jì)和我們中國(guó)網(wǎng)頁(yè)(尤其

2、是新浪的網(wǎng)頁(yè)者是負(fù)面的例子?！耙思摇?IKEA簡(jiǎn)約、效率的家居設(shè)計(jì)、生產(chǎn)思路;“微軟”(Microsoft“所見(jiàn)即所得”的理念;“谷歌”(Google簡(jiǎn)約、直接的商業(yè)風(fēng)格,無(wú)一例外的遵循了“kiss”原則,也正是“kiss”原則,成就了這些看似神奇的商業(yè)經(jīng)典。而蘋果公司的iPhone/iPad將這個(gè)原則實(shí)踐到了極至。把一個(gè)事情搞復(fù)雜是一件簡(jiǎn)單的事,但要把一個(gè)復(fù)雜的事變簡(jiǎn)單,這是一件復(fù)雜的事。Program to an interface, not an implementation這是設(shè)計(jì)模式中最根本的哲學(xué),注重接口,而不是實(shí)現(xiàn),依賴接口,而不是實(shí)現(xiàn)。接口是抽象是穩(wěn)定的,實(shí)現(xiàn)則是多種多樣的。以

3、后面我們會(huì)面向?qū)ο蟮腟OLID 原則中會(huì)提到我們的依賴倒置原則,就是這個(gè)原則的的另一種樣子。還有一條原則叫Composition over inheritance(喜歡組合而不是繼承,這兩條是那23個(gè)經(jīng)典設(shè)計(jì)模式中的設(shè)計(jì)原則。Command-Query Separation (CQS 命令-查詢分離原則查詢:當(dāng)一個(gè)方法返回一個(gè)值來(lái)回應(yīng)一個(gè)問(wèn)題的時(shí)候,它就具有查詢的性質(zhì);命令:當(dāng)一個(gè)方法要改變對(duì)象的狀態(tài)的時(shí)候,它就具有命令的性質(zhì);通常,一個(gè)方法可能是純的Command模式或者是純的Query模式,或者是兩者的混合體。在設(shè)計(jì)接口時(shí),如果可能,應(yīng)該盡量使接口單一化,保證方法的行為嚴(yán)格的是命令或者是查

4、詢,這樣查詢方法不會(huì)改變對(duì)象的狀態(tài),沒(méi)有副作用,而會(huì)改變對(duì)象的狀態(tài)的方法不可能有返回值。也就是說(shuō):如果我們要問(wèn)一個(gè)問(wèn)題,那么就不應(yīng)該影響到它的答案。實(shí)際應(yīng)用,要視具體情況而定,語(yǔ)義的清晰性和使用的簡(jiǎn)單性之間需要權(quán)衡。將Command和Query功能合并入一個(gè)方法,方便了客戶的使用,但是,降低了清晰性,而且,可能不便于基于斷言的程序設(shè)計(jì)并且需要一個(gè)變量來(lái)保存查詢結(jié)果。在系統(tǒng)設(shè)計(jì)中,很多系統(tǒng)也是以這樣原則設(shè)計(jì)的,查詢的功能和命令功能的系統(tǒng)分離,這樣有則于系統(tǒng)性能,也有利于系統(tǒng)的安全性。You Aint Gonna Need It (YAGNI這個(gè)原則簡(jiǎn)而言之為只考慮和設(shè)計(jì)必須的功能,避免過(guò)度設(shè)計(jì)。

5、只實(shí)現(xiàn)目前需要的功能,在以后您需要更多功能時(shí),可以再進(jìn)行添加。如無(wú)必要,勿增復(fù)雜性。軟件開(kāi)發(fā)先是一場(chǎng)溝通博弈。以前本站有一篇關(guān)于過(guò)度重構(gòu)的文章,這個(gè)示例就是這個(gè)原則的反例。而, WebSphere的設(shè)計(jì)者就表示過(guò)他過(guò)度設(shè)計(jì)了這個(gè)產(chǎn)品。我們的程序員或是架構(gòu)師在設(shè)計(jì)系統(tǒng)的時(shí)候,會(huì)考慮很多擴(kuò)展性的東西,導(dǎo)致在架構(gòu)與設(shè)計(jì)方面使用了大量折衷,最后導(dǎo)致項(xiàng)目失敗。這是個(gè)令人感到諷刺的教訓(xùn),因?yàn)楸緛?lái)希望盡可能延長(zhǎng)項(xiàng)目的生命周期,結(jié)果反而縮短了生命周期。Law of Demeter 迪米特法則迪米特法則(Law of Demeter,又稱“最少知識(shí)原則”(Principle of Least Knowledge

6、,其來(lái)源于1987年荷蘭大學(xué)的一個(gè)叫做Demeter的項(xiàng)目。Craig Larman把Law of Demeter又稱作“不要和陌生人說(shuō)話”。在程序員修煉之道中講LoD的那一章叫作“解耦合與迪米特法則”。關(guān)于迪米特法則有一些很形象的比喻:如果你想讓你的狗跑的話,你會(huì)對(duì)狗狗說(shuō)還是對(duì)四條狗腿說(shuō)?如果你去店里買東西,你會(huì)把錢交給店員,還是會(huì)把錢包交給店員讓他自己拿?和狗的四肢說(shuō)話?讓店員自己從錢包里拿錢?這聽(tīng)起來(lái)有點(diǎn)荒唐,不過(guò)在我們的代碼里這幾乎是見(jiàn)怪不怪的事情了。對(duì)于LoD,正式的表述如下:對(duì)于對(duì)象O 中一個(gè)方法M,M應(yīng)該只能夠訪問(wèn)以下對(duì)象中的方法:1.對(duì)象O;2.與O直接相關(guān)的Component

7、 Object;3.由方法M創(chuàng)建或者實(shí)例化的對(duì)象;4.作為方法M的參數(shù)的對(duì)象。在Clean Code一書(shū)中,有一段Apache framework中的一段違反了LoD的代碼:final String outputDir =ctxt.getOptions(.getScratchDir(.getAbsolutePath(;這么長(zhǎng)的一串對(duì)其它對(duì)象的細(xì)節(jié),以及細(xì)節(jié)的細(xì)節(jié),細(xì)節(jié)的細(xì)節(jié)的細(xì)節(jié)的調(diào)用,增加了耦合,使得代碼結(jié)構(gòu)復(fù)雜、僵化,難以擴(kuò)展和維護(hù)。在重構(gòu)一書(shū)中的代碼的環(huán)味道中有一種叫做“Feature Envy”(依戀情結(jié),形象的描述了一種違反了LoC的情況。Feature Envy就是說(shuō)一個(gè)對(duì)象對(duì)其它

8、對(duì)象的內(nèi)容更有興趣,也就是說(shuō)老是羨慕別的對(duì)象的成員、結(jié)構(gòu)或者功能,大老遠(yuǎn)的調(diào)用人家的東西。這樣的結(jié)構(gòu)顯然是不合理的。我們的程序應(yīng)該寫得比較“害羞”。不能像前面例子中的那個(gè)不把自己當(dāng)外人的店員一樣,拿過(guò)客人的錢包自己把錢拿出來(lái)?！昂π摺钡某绦蛑缓妥约鹤罱呐笥呀徽?。這種情況下應(yīng)該調(diào)整程序的結(jié)構(gòu),讓那個(gè)對(duì)象自己擁有它羨慕的feature,或者使用合理的設(shè)計(jì)模式(例如Facade和Mediator。一般來(lái)說(shuō)這是面向?qū)ο蟮奈宕笤O(shè)計(jì)原則,但是,我覺(jué)得這些原則可適用于所有的軟件開(kāi)發(fā)。Single Responsibility Principle (SRP 職責(zé)單一原則關(guān)于單一職責(zé)原則,其核心的思想是:一個(gè)

9、類,只做一件事,并把這件事做好,其只有一個(gè)引起它變化的原因。單一職責(zé)原則可以看作是低耦合、高內(nèi)聚在面向?qū)ο笤瓌t上的引申,將職責(zé)定義為引起變化的原因,以提高內(nèi)聚性來(lái)減少引起變化的原因。職責(zé)過(guò)多,可能引起它變化的原因就越多,這將導(dǎo)致職責(zé)依賴,相互之間就產(chǎn)生影響,從而極大的損傷其內(nèi)聚性和耦合度。單一職責(zé),通常意味著單一的功能,因此不要為一個(gè)模塊實(shí)現(xiàn)過(guò)多的功能點(diǎn),以保證實(shí)體只有一個(gè)引起它變化的原因。Unix/Linux是這一原則的完美體現(xiàn)者。各個(gè)程序都獨(dú)立負(fù)責(zé)一個(gè)單一的事。Windows是這一原則的反面示例。幾乎所有的程序都交織耦合在一起。Open/Closed Principle (OCP 開(kāi)閉原則

10、關(guān)于開(kāi)發(fā)封閉原則,其核心的思想是:模塊是可擴(kuò)展的,而不可修改的。也就是說(shuō),對(duì)擴(kuò)展是開(kāi)放的,而對(duì)修改是封閉的。對(duì)擴(kuò)展開(kāi)放,意味著有新的需求或變化時(shí),可以對(duì)現(xiàn)有代碼進(jìn)行擴(kuò)展,以適應(yīng)新的情況。對(duì)修改封閉,意味著類一旦設(shè)計(jì)完成,就可以獨(dú)立完成其工作,而不要對(duì)類進(jìn)行任何修改。對(duì)于面向?qū)ο髞?lái)說(shuō),需要你依賴抽象,而不是實(shí)現(xiàn),23個(gè)經(jīng)典設(shè)計(jì)模式中的“策略模式”就是這個(gè)實(shí)現(xiàn)。對(duì)于非面向?qū)ο缶幊?一些API需要你傳入一個(gè)你可以擴(kuò)展的函數(shù),比如我們的C 語(yǔ)言的qsort(允許你提供一個(gè)“比較器”,STL中的容器類的內(nèi)存分配,ACE中的多線程的各種鎖。對(duì)于軟件方面,瀏覽器的各種插件屬于這個(gè)原則的實(shí)踐。Liskov s

11、ubstitution principle (LSP 里氏代換原則軟件工程大師Robert C. Martin把里氏代換原則最終簡(jiǎn)化為一句話:“Subtypes must be substitutable for their base types”。也就是,子類必須能夠替換成它們的基類。即:子類應(yīng)該可以替換任何基類能夠出現(xiàn)的地方,并且經(jīng)過(guò)替換以后,代碼還能正常工作。另外,不應(yīng)該在代碼中出現(xiàn)if/else之類對(duì)子類類型進(jìn)行判斷的條件。里氏替換原則LSP是使代碼符合開(kāi)閉原則的一個(gè)重要保證。正是由于子類型的可替換性才使得父類型的模塊在無(wú)需修改的情況下就可以擴(kuò)展。這么說(shuō)來(lái),似乎有點(diǎn)教條化,我非常建議大

12、家看看這個(gè)原則個(gè)兩個(gè)最經(jīng)典的案例“正方形不是長(zhǎng)方形”和“鴕鳥(niǎo)不是鳥(niǎo)”。通過(guò)這兩個(gè)案例,你會(huì)明白墨子小取中說(shuō)的“娣,美人也,愛(ài)娣,非愛(ài)美人也.盜,人也;惡盜,非惡人也?！泵妹秒m然是美人,但喜歡妹妹并不代表喜歡美人。盜賊是人,但討厭盜賊也并不代表就討厭人類。這個(gè)原則讓你考慮的不是語(yǔ)義上對(duì)象的間的關(guān)系,而是實(shí)際需求的環(huán)境。在很多情況下,在設(shè)計(jì)初期我們類之間的關(guān)系不是很明確,LSP則給了我們一個(gè)判斷和設(shè)計(jì)類之間關(guān)系的基準(zhǔn):需不需要繼承,以及怎樣設(shè)計(jì)繼承關(guān)系。Interface Segregation Principle (ISP 接口隔離原則接口隔離原則意思是把功能實(shí)現(xiàn)在接口中,而不是類中,使用多個(gè)專

13、門的接口比使用單一的總接口要好。舉個(gè)例子,我們對(duì)電腦有不同的使用方式,比如:寫作,通訊,看電影,打游戲,上網(wǎng),編程,計(jì)算,數(shù)據(jù)等,如果我們把這些功能都聲明在電腦的抽類里面,那么,我們的上網(wǎng)本,PC機(jī),服務(wù)器,筆記本的實(shí)現(xiàn)類都要實(shí)現(xiàn)所有的這些接口,這就顯得太復(fù)雜了。所以,我們可以把其這些功能接口隔離開(kāi)來(lái),比如:工作學(xué)習(xí)接口,編程開(kāi)發(fā)接口,上網(wǎng)娛樂(lè)接口,計(jì)算和數(shù)據(jù)服務(wù)接口,這樣,我們的不同功能的電腦就可以有所選擇地繼承這些接口。這個(gè)原則可以提升我們“搭積木式”的軟件開(kāi)發(fā)。對(duì)于設(shè)計(jì)來(lái)說(shuō),Java中的各種Event Listener和Adapter,對(duì)于軟件開(kāi)發(fā)來(lái)說(shuō),不同的用戶權(quán)限有不同的功能,不同的

14、版本有不同的功能,都是這個(gè)原則的應(yīng)用。Dependency Inversion Principle (DIP 依賴倒置原則高層模塊不應(yīng)該依賴于低層模塊的實(shí)現(xiàn),而是依賴于高層抽象。舉個(gè)例子,墻面的開(kāi)關(guān)不應(yīng)該依賴于電燈的開(kāi)關(guān)實(shí)現(xiàn),而是應(yīng)該依賴于一個(gè)抽象的開(kāi)關(guān)的標(biāo)準(zhǔn)接口,這樣,當(dāng)我們擴(kuò)展程序的時(shí)候,我們的開(kāi)關(guān)同樣可以控制其它不同的燈,甚至不同的電器。也就是說(shuō),電燈和其它電器繼承并實(shí)現(xiàn)我們的標(biāo)準(zhǔn)開(kāi)關(guān)接口,而我們的開(kāi)關(guān)產(chǎn)商就可不需要關(guān)于其要控制什么樣的設(shè)備,只需要關(guān)心那個(gè)標(biāo)準(zhǔn)的開(kāi)關(guān)標(biāo)準(zhǔn)。這就是依賴倒置原則。這就好像瀏覽器并不依賴于后面的web服務(wù)器,其只依賴于HTTP協(xié)議。這個(gè)原則實(shí)在是太重要了,社會(huì)的

15、分工化,標(biāo)準(zhǔn)化都是這個(gè)設(shè)計(jì)原則的體現(xiàn)。Common Closure Principle(CCP共同封閉原則一個(gè)包中所有的類應(yīng)該對(duì)同一種類型的變化關(guān)閉。一個(gè)變化影響一個(gè)包,便影響了包中所有的類。一個(gè)更簡(jiǎn)短的說(shuō)法是:一起修改的類,應(yīng)該組合在一起(同一個(gè)包里。如果必須修改應(yīng)用程序里的代碼,我們希望所有的修改都發(fā)生在一個(gè)包里(修改關(guān)閉,而不是遍布在很多包里。CCP原則就是把因?yàn)槟硞€(gè)同樣的原因而需要修改的所有類組合進(jìn)一個(gè)包里。如果2個(gè)類從物理上或者從概念上聯(lián)系得非常緊密,它們通常一起發(fā)生改變,那么它們應(yīng)該屬于同一個(gè)包。CCP延伸了開(kāi)閉原則(OCP的“關(guān)閉”概念,當(dāng)因?yàn)槟硞€(gè)原因需要修改時(shí),把需要修改的范圍

16、限制在一個(gè)最小范圍內(nèi)的包里。Common Reuse Principle (CRP 共同重用原則包的所有類被一起重用。如果你重用了其中的一個(gè)類,就重用全部。換個(gè)說(shuō)法是,沒(méi)有被一起重用的類不應(yīng)該被組合在一起。CRP原則幫助我們決定哪些類應(yīng)該被放到同一個(gè)包里。依賴一個(gè)包就是依賴這個(gè)包所包含的一切。當(dāng)一個(gè)包發(fā)生了改變,并發(fā)布新的版本,使用這個(gè)包的所有用戶都必須在新的包環(huán)境下驗(yàn)證他們的工作,即使被他們使用的部分沒(méi)有發(fā)生任何改變。因?yàn)槿绻邪形幢皇褂玫念?即使用戶不關(guān)心該類是否改變,但用戶還是不得不升級(jí)該包并對(duì)原來(lái)的功能加以重新測(cè)試。CCP則讓系統(tǒng)的維護(hù)者受益。CCP讓包盡可能大(CCP原則加入功

17、能相關(guān)的類, CRP則讓包盡可能小(CRP原則剔除不使用的類。它們的出發(fā)點(diǎn)不一樣,但不相互沖突。Hollywood Principle 好萊塢原則好萊塢原則就是一句話“dont call us, well call you.”。意思是,好萊塢的經(jīng)紀(jì)人們不希望你去聯(lián)系他們,而是他們會(huì)在需要的時(shí)候來(lái)聯(lián)系你。也就是說(shuō),所有的組件都是被動(dòng)的,所有的組件初始化和調(diào)用都由容器負(fù)責(zé)。組件處在一個(gè)容器當(dāng)中,由容器負(fù)責(zé)管理。簡(jiǎn)單的來(lái)講,就是由容器控制程序之間的關(guān)系,而非傳統(tǒng)實(shí)現(xiàn)中,由程序代碼直接操控。這也就是所謂“控制反轉(zhuǎn)”的概念所在:1.不創(chuàng)建對(duì)象,而是描述創(chuàng)建對(duì)象的方式。2.在代碼中,對(duì)象與服務(wù)沒(méi)有直接聯(lián)系

18、,而是容器負(fù)責(zé)將這些聯(lián)系在一起?？刂茩?quán)由應(yīng)用代碼中轉(zhuǎn)到了外部容器，控制權(quán)的轉(zhuǎn)移，是所謂反轉(zhuǎn)。 好萊塢原則就是 IoC（Inversion of Control）或 DI（Dependency Injection ） 的基礎(chǔ)原則。這個(gè)原則很像依賴倒置原則，依賴接口，而不是實(shí)例，但是這個(gè)原 則要解決的是怎么把這個(gè)實(shí)例傳入調(diào)用類中？你可能把其聲明成成員， 你可以通 過(guò)構(gòu)造函數(shù)，你可以通過(guò)函數(shù)參數(shù)。但是 IoC 可以讓你通過(guò)配置文件，一個(gè)由 Service Container 讀取的配置文件來(lái)產(chǎn)生實(shí)際配置的類。但是程序也有可能變 高內(nèi)聚， High Cohesion & Low/Loose c

19、oupling & 高內(nèi)聚， 低耦合 這個(gè)原則是 UNIX 操作系統(tǒng)設(shè)計(jì)的經(jīng)典原則，把模塊間的耦合降到最低，而努力 讓一個(gè)模塊做到精益求精。 內(nèi)聚：一個(gè)模塊內(nèi)各個(gè)元素彼此結(jié)合的緊密程度 耦合：一個(gè)軟件結(jié)構(gòu)內(nèi)不同模塊之間互連程度的度量 內(nèi)聚意味著重用和獨(dú)立，耦合意味著多米諾效應(yīng)牽一發(fā)動(dòng)全身。 Configuration（CoC） Convention over Configuration（CoC） 慣例優(yōu)于配置原則 簡(jiǎn)單點(diǎn)說(shuō)， 就是將一些公認(rèn)的配置方式和信息作為內(nèi)部缺省的規(guī)則來(lái)使用。 例如， Hibernate 的映射文件，如果約定字段名和類屬性一致的話，基本上就可以不要 這個(gè)配置文件了

20、。你的應(yīng)用只需要指定不 convention 的信息即可，從而減少了 大量 convention 而又不得不花時(shí)間和精力啰里啰嗦的東東。配置文件很多時(shí)候 相當(dāng)?shù)挠绊戦_(kāi)發(fā)效率。 Rails 中很少有配置文件 （但不是沒(méi)有， 數(shù)據(jù)庫(kù)連接就是一個(gè)配置文件） Rails ， 的 fans 號(hào)稱期開(kāi)發(fā)效率是 java 開(kāi)發(fā)的 10 倍，估計(jì)就是這個(gè)原因。Maven 也 使用了 CoC 原則，當(dāng)你執(zhí)行 mvn -compile 命令的時(shí)候，不需要指源文件放在什 么地方， 而編譯以后的 class 文件放置在什么地方也沒(méi)有指定， 這就是 CoC 原則。 Separation of Concerns (SoC

21、 關(guān)注點(diǎn)分離 SoC 是計(jì)算機(jī)科學(xué)中最重要的努力目標(biāo)之一。這個(gè)原則，就是在軟件開(kāi)發(fā)中，通 過(guò)各種手段，將問(wèn)題的各個(gè)關(guān)注點(diǎn)分開(kāi)。如果一個(gè)問(wèn)題能分解為獨(dú)立且較小的問(wèn) 題，就是相對(duì)較易解決的。問(wèn)題太過(guò)于復(fù)雜，要解決問(wèn)題需要關(guān)注的點(diǎn)太多，而 程序員的能力是有限的，不能同時(shí)關(guān)注于問(wèn)題的各個(gè)方面。正如程序員的記憶力 相對(duì)于計(jì)算機(jī)知識(shí)來(lái)說(shuō)那么有限一樣， 程序員解決問(wèn)題的能力相對(duì)于要解決的問(wèn) 題的復(fù)雜性也是一樣的非常有限。在我們分析問(wèn)題的時(shí)候，如果我們把所有的東 西混在一起討論，那么就只會(huì)有一個(gè)結(jié)果亂。 我記得在上一家公司有一個(gè)項(xiàng)目，討論就討論了 1 年多，項(xiàng)目本來(lái)不復(fù)雜，但是 沒(méi)有使用 SoC，全部的東西混

22、為一談，再加上一堆程序員注入了各種不同的觀點(diǎn) 和想法，整個(gè)項(xiàng)目一下子就失控了。最后，本來(lái)一個(gè) 1 年的項(xiàng)目做了 3 年。 實(shí)現(xiàn)關(guān)注點(diǎn)分離的方法主要有兩種，一種是標(biāo)準(zhǔn)化，另一種是抽象與包裝。標(biāo)準(zhǔn) 化就是制定一套標(biāo)準(zhǔn)，讓使用者都遵守它，將人們的行為統(tǒng)一起來(lái)，這樣使用標(biāo) 準(zhǔn)的人就不用擔(dān)心別人會(huì)有很多種不同的實(shí)現(xiàn)， 使自己的程序不能和別人的配合。 Java EE 就是一個(gè)標(biāo)準(zhǔn)的大集合。每個(gè)開(kāi)發(fā)者只需要關(guān)注于標(biāo)準(zhǔn)本身和他所在做 的事情就行了。就像是開(kāi)發(fā)鏍絲釘?shù)娜酥粚Ｗ⒂陂_(kāi)發(fā)鏍絲釘就行了，而不用關(guān)注 鏍帽是怎么生產(chǎn)的，反正鏍帽和鏍絲釘按標(biāo)來(lái)就一定能合得上。不斷地把程序的 某些部分抽像差包裝起來(lái)，也是實(shí)現(xiàn)關(guān)

23、注點(diǎn)分離的好方法。一旦一個(gè)函數(shù)被抽像 出來(lái)并實(shí)現(xiàn)了，那么使用函數(shù)的人就不用關(guān)心這個(gè)函數(shù)是如何實(shí)現(xiàn)的，同樣的， 一旦一個(gè)類被抽像并實(shí)現(xiàn)了， 類的使用者也不用再關(guān)注于這個(gè)類的內(nèi)部是如何實(shí) 現(xiàn)的。諸如組件，分層，面向服務(wù)，等等這些概念都是在不同的層次上做抽像和 包裝，以使得使用者不用關(guān)心它的內(nèi)部實(shí)現(xiàn)細(xì)節(jié)。 說(shuō)白了還是“高內(nèi)聚，低耦合”。 Design by Contract (DbC 契約式設(shè)計(jì) DbC 的核心思想是對(duì)軟件系統(tǒng)中的元素之間相互合作以及“責(zé)任”與“義務(wù)” 的比喻。這種比喻從商業(yè)活動(dòng)中“客戶”與“供應(yīng)商”達(dá)成“契約”而得來(lái)。例 如： 供應(yīng)商必須提供某種產(chǎn)品 （責(zé)任） 并且他有權(quán)期望客戶已

24、經(jīng)付款 ， （權(quán)利） 。 客戶必須付款（責(zé)任），并且有權(quán)得到產(chǎn)品（權(quán)利）。 契約雙方必須履行那些對(duì)所有契約都有效的責(zé)任，如法律和規(guī)定等。 同樣的，如果在程序設(shè)計(jì)中一個(gè)模塊提供了某種功能，那么它要： 期望所有調(diào)用它的客戶模塊都保證一定的進(jìn)入條件： 這就是模塊的先驗(yàn)條 件（客戶的義務(wù)和供應(yīng)商的權(quán)利，這樣它就不用去處理不滿足先驗(yàn)條件的 情況）。 保證退出時(shí)給出特定的屬性： 這就是模塊的后驗(yàn)條件 （供應(yīng)商的義務(wù)， 顯然也是客戶的權(quán)利）。 在進(jìn)入時(shí)假定，并在退出時(shí)保持一些特定的屬性：不變式。 契約就是這些權(quán)利和義務(wù)的正式形式。我們可以用“三個(gè)問(wèn)題”來(lái)總結(jié) DbC，并 且作為設(shè)計(jì)者要經(jīng)常問(wèn)： 它期望的是什么？ 它要保證的是什么？ 它要保持的是什么？ 根據(jù) Bertrand Meyer 氏提出的 DBC 概念的描述，對(duì)于類的一個(gè)方法，都有一個(gè) 前提條件以及一個(gè)后續(xù)條件，前提條件說(shuō)明方法接受什么樣的參數(shù)數(shù)據(jù)等，只有 前提條件得到滿足時(shí)，這個(gè)方法才能被調(diào)用；同時(shí)后續(xù)條件用來(lái)說(shuō)明這個(gè)方法完 成時(shí)的狀態(tài)，如果一個(gè)方法的執(zhí)行會(huì)導(dǎo)致這個(gè)方法的后續(xù)條件不成立，那么這個(gè) 方法也不應(yīng)該正常返回。 現(xiàn)在把前提條件以及后續(xù)條件應(yīng)用到繼承子類中，子類方法應(yīng)該滿足： 1. 前提條件不強(qiáng)于基類 2. 后續(xù)條件不弱于基類 換句話說(shuō)，通