|
|
以前本站向大家介紹過一些軟件開發(fā)的原則，比如優(yōu)質(zhì)代碼的十誡和Unix傳奇(下篇)中所以說的UNIX的設(shè)計(jì)原則。相信大家從中能夠從中學(xué)了解到一些設(shè)計(jì)原理方面的知識(shí)，正如我在《再談“我是怎么招聘程序”》中所說的，一個(gè)好的程序員通常由其操作技能、知識(shí)水平，經(jīng)驗(yàn)層力和能力四個(gè)方面組成。在這里想和大家說說設(shè)計(jì)中的一些原則，我認(rèn)為這些東西屬于長期經(jīng)驗(yàn)總結(jié)出來的知識(shí)。這些原則，每一個(gè)程序員都應(yīng)該了解。但是請不要教條主義，在使用的時(shí)候還是要多多考慮實(shí)際情況。
其，下面這些原則，不單單只是軟件開發(fā)，可以推廣到其它生產(chǎn)活動(dòng)中，甚至我們的生活中。
Don’t Repeat Yourself (DRY)
DRY 是一個(gè)最簡單的法則，也是最容易被理解的。但它也可能是最難被應(yīng)用的（因?yàn)橐龅竭@樣，我們需要在泛型設(shè)計(jì)上做相當(dāng)?shù)呐Γ@并不是一件容易的事）。它意味著，當(dāng)我們在兩個(gè)或多個(gè)地方的時(shí)候發(fā)現(xiàn)一些相似的代碼的時(shí)候，我們需要把他們的共性抽象出來形一個(gè)唯一的新方法，并且改變現(xiàn)有的地方的代碼讓他們以一些合適的參數(shù)調(diào)用這個(gè)新的方法。
參考：http://en.wikipedia.org/wiki/Don%27t_repeat_yourself
Keep It Simple, Stupid (KISS)
KISS原則在設(shè)計(jì)上可能最被推崇的，在家裝設(shè)計(jì)，界面設(shè)計(jì)，操作設(shè)計(jì)上，復(fù)雜的東西越來越被眾人所BS了，而簡單的東西越來越被人所認(rèn)可，比如這些UI的設(shè)計(jì)和我們中國網(wǎng)頁（尤其是新浪的網(wǎng)頁）者是負(fù)面的例子。“宜家”（IKEA）簡約、效率的家居設(shè)計(jì)、生產(chǎn)思路；“微軟”（Microsoft）“所見即所得”的理念；“谷歌”（Google)簡約、直接的商業(yè)風(fēng)格，無一例外的遵循了“kiss”原則，也正是“kiss”原則，成就了這些看似神奇的商業(yè)經(jīng)典。而蘋果公司的iPhone/iPad將這個(gè)原則實(shí)踐到了極至。
把一個(gè)事情搞復(fù)雜是一件簡單的事，但要把一個(gè)復(fù)雜的事變簡單，這是一件復(fù)雜的事。
參考：http://en.wikipedia.org/wiki/KISS_principle
Program to an interface, not an implementation
這是設(shè)計(jì)模式中最根本的哲學(xué)，注重接口，而不是實(shí)現(xiàn)，依賴接口，而不是實(shí)現(xiàn)。接口是抽象是穩(wěn)定的，實(shí)現(xiàn)則是多種多樣的。以后面我們會(huì)面向?qū)ο蟮腟OLID原則中會(huì)提到我們的依賴倒置原則，就是這個(gè)原則的的另一種樣子。還有一條原則叫 Composition over inheritance（喜歡組合而不是繼承），這兩條是那23個(gè)經(jīng)典設(shè)計(jì)模式中的設(shè)計(jì)原則。
Command-Query Separation (CQS) –命令-查詢分離原則
- 查詢：當(dāng)一個(gè)方法返回一個(gè)值來回應(yīng)一個(gè)問題的時(shí)候，它就具有查詢的性質(zhì)；
- 命令：當(dāng)一個(gè)方法要改變對象的狀態(tài)的時(shí)候，它就具有命令的性質(zhì)；
通常，一個(gè)方法可能是純的Command模式或者是純的Query模式，或者是兩者的混合體。在設(shè)計(jì)接口時(shí)，如果可能，應(yīng)該盡量使接口單一化，保證方法的行為嚴(yán)格的是命令或者是查詢，這樣查詢方法不會(huì)改變對象的狀態(tài)，沒有副作用，而會(huì)改變對象的狀態(tài)的方法不可能有返回值。也就是說：如果我們要問一個(gè)問題，那么就不應(yīng)該影響到它的答案。實(shí)際應(yīng)用，要視具體情況而定，語義的清晰性和使用的簡單性之間需要權(quán)衡。將Command和Query功能合并入一個(gè)方法，方便了客戶的使用，但是，降低了清晰性，而且，可能不便于基于斷言的程序設(shè)計(jì)并且需要一個(gè)變量來保存查詢結(jié)果。
在系統(tǒng)設(shè)計(jì)中，很多系統(tǒng)也是以這樣原則設(shè)計(jì)的，查詢的功能和命令功能的系統(tǒng)分離，這樣有則于系統(tǒng)性能，也有利于系統(tǒng)的安全性。
參考：http://en.wikipedia.org/wiki/Command-query_separation
You Ain’t Gonna Need It (YAGNI)
這個(gè)原則簡而言之為——只考慮和設(shè)計(jì)必須的功能，避免過度設(shè)計(jì)。只實(shí)現(xiàn)目前需要的功能，在以后您需要更多功能時(shí)，可以再進(jìn)行添加。
- 如無必要，勿增復(fù)雜性。
- 軟件開發(fā)先是一場溝通博弈。
以前本站有一篇關(guān)于過度重構(gòu)的文章，這個(gè)示例就是這個(gè)原則的反例。而，WebSphere的設(shè)計(jì)者就表示過他過度設(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)楸緛硐ＭM可能延長項(xiàng)目的生命周期，結(jié)果反而縮短了生命周期。
參考：http://en.wikipedia.org/wiki/You_Ain%27t_Gonna_Need_It
Law of Demeter –迪米特法則
迪米特法則(Law of Demeter)，又稱“最少知識(shí)原則”（Principle of Least Knowledge），其來源于1987年荷蘭大學(xué)的一個(gè)叫做Demeter的項(xiàng)目。Craig Larman把Law of Demeter又稱作“不要和陌生人說話”。在《程序員修煉之道》中講LoD的那一章叫作“解耦合與迪米特法則”。關(guān)于迪米特法則有一些很形象的比喻：
- 如果你想讓你的狗跑的話，你會(huì)對狗狗說還是對四條狗腿說？
- 如果你去店里買東西，你會(huì)把錢交給店員，還是會(huì)把錢包交給店員讓他自己拿？
和狗的四肢說話？讓店員自己從錢包里拿錢？這聽起來有點(diǎn)荒唐，不過在我們的代碼里這幾乎是見怪不怪的事情了。
對于LoD，正式的表述如下：
對于對象‘O’中一個(gè)方法’M'，M應(yīng)該只能夠訪問以下對象中的方法：
- 對象O；
- 與O直接相關(guān)的Component Object；
- 由方法M創(chuàng)建或者實(shí)例化的對象；
- 作為方法M的參數(shù)的對象。
在《Clean Code》一書中，有一段Apache framework中的一段違反了LoD的代碼：
final String outputDir = ctxt.getOptions().getScratchDir().getAbsolutePath();
這么長的一串對其它對象的細(xì)節(jié)，以及細(xì)節(jié)的細(xì)節(jié)，細(xì)節(jié)的細(xì)節(jié)的細(xì)節(jié)……的調(diào)用，增加了耦合，使得代碼結(jié)構(gòu)復(fù)雜、僵化，難以擴(kuò)展和維護(hù)。
在《重構(gòu)》一書中的代碼的環(huán)味道中有一種叫做“Feature Envy”(依戀情結(jié)），形象的描述了一種違反了LoC的情況。Feature Envy就是說一個(gè)對象對其它對象的內(nèi)容更有興趣，也就是說老是羨慕別的對象的成員、結(jié)構(gòu)或者功能，大老遠(yuǎn)的調(diào)用人家的東西。這樣的結(jié)構(gòu)顯然是不合理的。我們的程序應(yīng)該寫得比較“害羞”。不能像前面例子中的那個(gè)不把自己當(dāng)外人的店員一樣，拿過客人的錢包自己把錢拿出來。“害羞”的程序只和自己最近的朋友交談。這種情況下應(yīng)該調(diào)整程序的結(jié)構(gòu)，讓那個(gè)對象自己擁有它羨慕的feature，或者使用合理的設(shè)計(jì)模式（例如Facade和Mediator）。
參考：http://en.wikipedia.org/wiki/Principle_of_Least_Knowledge
面向?qū)ο蟮腟.O.L.I.D 原則
一般來說這是面向?qū)ο蟮奈宕笤O(shè)計(jì)原則，但是，我覺得這些原則可適用于所有的軟件開發(fā)。
Single Responsibility Principle (SRP) –職責(zé)單一原則
關(guān)于單一職責(zé)原則，其核心的思想是：一個(gè)類，只做一件事，并把這件事做好，其只有一個(gè)引起它變化的原因。單一職責(zé)原則可以看作是低耦合、高內(nèi)聚在面向?qū)ο笤瓌t上的引申，將職責(zé)定義為引起變化的原因，以提高內(nèi)聚性來減少引起變化的原因。職責(zé)過多，可能引起它變化的原因就越多，這將導(dǎo)致職責(zé)依賴，相互之間就產(chǎn)生影響，從而極大的損傷其內(nèi)聚性和耦合度。單一職責(zé)，通常意味著單一的功能，因此不要為一個(gè)模塊實(shí)現(xiàn)過多的功能點(diǎn)，以保證實(shí)體只有一個(gè)引起它變化的原因。
- Unix/Linux是這一原則的完美體現(xiàn)者。各個(gè)程序都獨(dú)立負(fù)責(zé)一個(gè)單一的事。
- Windows是這一原則的反面示例。幾乎所有的程序都交織耦合在一起。
Open/Closed Principle (OCP) –開閉原則
關(guān)于開發(fā)封閉原則，其核心的思想是：模塊是可擴(kuò)展的，而不可修改的。也就是說，對擴(kuò)展是開放的，而對修改是封閉的。
- 對擴(kuò)展開放，意味著有新的需求或變化時(shí)，可以對現(xiàn)有代碼進(jìn)行擴(kuò)展，以適應(yīng)新的情況。
- 對修改封閉，意味著類一旦設(shè)計(jì)完成，就可以獨(dú)立完成其工作，而不要對類進(jìn)行任何修改。
對于面向?qū)ο髞碚f，需要你依賴抽象，而不是實(shí)現(xiàn)，23個(gè)經(jīng)典設(shè)計(jì)模式中的“策略模式”就是這個(gè)實(shí)現(xiàn)。對于非面向?qū)ο缶幊?，一些API需要你傳入一個(gè)你可以擴(kuò)展的函數(shù)，比如我們的C 語言的qsort()允許你提供一個(gè)“比較器”，STL中的容器類的內(nèi)存分配，ACE中的多線程的各種鎖。對于軟件方面，瀏覽器的各種插件屬于這個(gè)原則的實(shí)踐。
Liskov substitution principle (LSP) –里氏代換原則
軟件工程大師Robert C. Martin把里氏代換原則最終簡化為一句話：“Subtypes must be substitutable for their base types”。也就是，子類必須能夠替換成它們的基類。即：子類應(yīng)該可以替換任何基類能夠出現(xiàn)的地方，并且經(jīng)過替換以后，代碼還能正常工作。另外，不應(yīng)該在代碼中出現(xiàn)if/else之類對子類類型進(jìn)行判斷的條件。里氏替換原則LSP是使代碼符合開閉原則的一個(gè)重要保證。正是由于子類型的可替換性才使得父類型的模塊在無需修改的情況下就可以擴(kuò)展。
這么說來，似乎有點(diǎn)教條化，我非常建議大家看看這個(gè)原則個(gè)兩個(gè)最經(jīng)典的案例——“正方形不是長方形”和“鴕鳥不是鳥”。通過這兩個(gè)案例，你會(huì)明白《墨子小取》中說的——“娣，美人也，愛娣，非愛美人也….盜，人也；惡盜，非惡人也。”——妹妹雖然是美人，但喜歡妹妹并不代表喜歡美人。盜賊是人，但討厭盜賊也并不代表就討厭人類。這個(gè)原則讓你考慮的不是語義上對象的間的關(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è)專門的接口比使用單一的總接口要好。
舉個(gè)例子，我們對電腦有不同的使用方式，比如：寫作，通訊，看電影，打游戲，上網(wǎng)，編程，計(jì)算，數(shù)據(jù)等，如果我們把這些功能都聲明在電腦的抽類里面，那么，我們的上網(wǎng)本，PC機(jī)，服務(wù)器，筆記本的實(shí)現(xiàn)類都要實(shí)現(xiàn)所有的這些接口，這就顯得太復(fù)雜了。所以，我們可以把其這些功能接口隔離開來，比如：工作學(xué)習(xí)接口，編程開發(fā)接口，上網(wǎng)娛樂接口，計(jì)算和數(shù)據(jù)服務(wù)接口，這樣，我們的不同功能的電腦就可以有所選擇地繼承這些接口。
這個(gè)原則可以提升我們“搭積木式”的軟件開發(fā)。對于設(shè)計(jì)來說，Java中的各種Event Listener和Adapter，對于軟件開發(fā)來說，不同的用戶權(quán)限有不同的功能，不同的版本有不同的功能，都是這個(gè)原則的應(yīng)用。
Dependency Inversion Principle (DIP) –依賴倒置原則
高層模塊不應(yīng)該依賴于低層模塊的實(shí)現(xiàn)，而是依賴于高層抽象。
舉個(gè)例子，墻面的開關(guān)不應(yīng)該依賴于電燈的開關(guān)實(shí)現(xiàn)，而是應(yīng)該依賴于一個(gè)抽象的開關(guān)的標(biāo)準(zhǔn)接口，這樣，當(dāng)我們擴(kuò)展程序的時(shí)候，我們的開關(guān)同樣可以控制其它不同的燈，甚至不同的電器。也就是說，電燈和其它電器繼承并實(shí)現(xiàn)我們的標(biāo)準(zhǔn)開關(guān)接口，而我們的開關(guān)產(chǎn)商就可不需要關(guān)于其要控制什么樣的設(shè)備，只需要關(guān)心那個(gè)標(biāo)準(zhǔn)的開關(guān)標(biāo)準(zhǔn)。這就是依賴倒置原則。
這就好像瀏覽器并不依賴于后面的web服務(wù)器，其只依賴于HTTP協(xié)議。這個(gè)原則實(shí)在是太重要了，社會(huì)的分工化，標(biāo)準(zhǔn)化都是這個(gè)設(shè)計(jì)原則的體現(xiàn)。
參考：http://en.wikipedia.org/wiki/Solid_(object-oriented_design)
Common Closure Principle（CCP）–共同封閉原則
一個(gè)包中所有的類應(yīng)該對同一種類型的變化關(guān)閉。一個(gè)變化影響一個(gè)包，便影響了包中所有的類。一個(gè)更簡短的說法是：一起修改的類，應(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延伸了開閉原則（OCP）的“關(guān)閉”概念，當(dāng)因?yàn)槟硞€(gè)原因需要修改時(shí)，把需要修改的范圍限制在一個(gè)最小范圍內(nèi)的包里。
參考：http://c2.com/cgi/wiki?CommonClosurePrinciple
Common Reuse Principle (CRP) –共同重用原則
包的所有類被一起重用。如果你重用了其中的一個(gè)類，就重用全部。換個(gè)說法是，沒有被一起重用的類不應(yīng)該被組合在一起。CRP原則幫助我們決定哪些類應(yīng)該被放到同一個(gè)包里。依賴一個(gè)包就是依賴這個(gè)包所包含的一切。當(dāng)一個(gè)包發(fā)生了改變，并發(fā)布新的版本，使用這個(gè)包的所有用戶都必須在新的包環(huán)境下驗(yàn)證他們的工作，即使被他們使用的部分沒有發(fā)生任何改變。因?yàn)槿绻邪形幢皇褂玫念?，即使用戶不關(guān)心該類是否改變，但用戶還是不得不升級(jí)該包并對原來的功能加以重新測試。
CCP則讓系統(tǒng)的維護(hù)者受益。CCP讓包盡可能大（CCP原則加入功能相關(guān)的類），CRP則讓包盡可能?。–RP原則剔除不使用的類）。它們的出發(fā)點(diǎn)不一樣，但不相互沖突。
參考：http://c2.com/cgi/wiki?CommonReusePrinciple
Hollywood Principle –好萊塢原則
好萊塢原則就是一句話——“don’t call us,we’ll call you.”。意思是，好萊塢的經(jīng)紀(jì)人們不希望你去聯(lián)系他們，而是他們會(huì)在需要的時(shí)候來聯(lián)系你。也就是說，所有的組件都是被動(dòng)的，所有的組件初始化和調(diào)用都由容器負(fù)責(zé)。組件處在一個(gè)容器當(dāng)中，由容器負(fù)責(zé)管理。
簡單的來講，就是由容器控制程序之間的關(guān)系，而非傳統(tǒng)實(shí)現(xiàn)中，由程序代碼直接操控。這也就是所謂“控制反轉(zhuǎn)”的概念所在：
- 不創(chuàng)建對象，而是描述創(chuàng)建對象的方式。
- 在代碼中，對象與服務(wù)沒有直接聯(lián)系，而是容器負(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)用類中？你可能把其聲明成成員，你可以通過構(gòu)造函數(shù)，你可以通過函數(shù)參數(shù)。但是 IoC可以讓你通過配置文件，一個(gè)由Service Container 讀取的配置文件來產(chǎn)生實(shí)際配置的類。但是程序也有可能變得不易讀了，程序的性能也有可能還會(huì)下降。
參考：
High Cohesion & Low/Loose coupling & –高內(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)全身。
參考：
- http://en.wikipedia.org/wiki/Coupling_(computer_science)
- http://en.wikipedia.org/wiki/Cohesion_(computer_science)
Convention over Configuration（CoC）–慣例優(yōu)于配置原則
簡單點(diǎn)說，就是將一些公認(rèn)的配置方式和信息作為內(nèi)部缺省的規(guī)則來使用。例如，Hibernate的映射文件，如果約定字段名和類屬性一致的話，基本上就可以不要這個(gè)配置文件了。你的應(yīng)用只需要指定不convention的信息即可，從而減少了大量convention而又不得不花時(shí)間和精力啰里啰嗦的東東。配置文件很多時(shí)候相當(dāng)?shù)挠绊戦_發(fā)效率。
Rails 中很少有配置文件（但不是沒有，數(shù)據(jù)庫連接就是一個(gè)配置文件），Rails 的fans號(hào)稱期開發(fā)效率是 Java 開發(fā)的 10 倍，估計(jì)就是這個(gè)原因。Maven也使用了CoC原則，當(dāng)你執(zhí)行mvn -compile命令的時(shí)候，不需要指源文件放在什么地方，而編譯以后的class文件放置在什么地方也沒有指定，這就是CoC原則。
參考：http://en.wikipedia.org/wiki/Convention_over_Configuration
Separation of Concerns (SoC) –關(guān)注點(diǎn)分離
SoC 是計(jì)算機(jī)科學(xué)中最重要的努力目標(biāo)之一。這個(gè)原則，就是在軟件開發(fā)中，通過各種手段，將問題的各個(gè)關(guān)注點(diǎn)分開。如果一個(gè)問題能分解為獨(dú)立且較小的問題，就是相對較易解決的。問題太過于復(fù)雜，要解決問題需要關(guān)注的點(diǎn)太多，而程序員的能力是有限的，不能同時(shí)關(guān)注于問題的各個(gè)方面。正如程序員的記憶力相對于計(jì)算機(jī)知識(shí)來說那么有限一樣，程序員解決問題的能力相對于要解決的問題的復(fù)雜性也是一樣的非常有限。在我們分析問題的時(shí)候，如果我們把所有的東西混在一起討論，那么就只會(huì)有一個(gè)結(jié)果——亂。
我記得在上一家公司有一個(gè)項(xiàng)目，討論就討論了1年多，項(xiàng)目本來不復(fù)雜，但是沒有使用SoC，全部的東西混為一談，再加上一堆程序員注入了各種不同的觀點(diǎn)和想法，整個(gè)項(xiàng)目一下子就失控了。最后，本來一個(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)一起來，這樣使用標(biāo)準(zhǔn)的人就不用擔(dān)心別人會(huì)有很多種不同的實(shí)現(xiàn)，使自己的程序不能和別人的配合。Java EE就是一個(gè)標(biāo)準(zhǔn)的大集合。每個(gè)開發(fā)者只需要關(guān)注于標(biāo)準(zhǔn)本身和他所在做的事情就行了。就像是開發(fā)鏍絲釘?shù)娜酥粚Ｗ⒂陂_發(fā)鏍絲釘就行了，而不用關(guān)注鏍帽是怎么生產(chǎn)的，反正鏍帽和鏍絲釘按標(biāo)來就一定能合得上。不斷地把程序的某些部分抽像差包裝起來，也是實(shí)現(xiàn)關(guān)注點(diǎn)分離的好方法。一旦一個(gè)函數(shù)被抽像出來并實(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é)。
說白了還是“高內(nèi)聚，低耦合”。
參考：http://sulong.me/archives/99
Design by Contract (DbC) –契約式設(shè)計(jì)
DbC的核心思想是對軟件系統(tǒng)中的元素之間相互合作以及“責(zé)任”與“義務(wù)”的比喻。這種比喻從商業(yè)活動(dòng)中“客戶”與“供應(yīng)商”達(dá)成“契約”而得來。例如：
- 供應(yīng)商必須提供某種產(chǎn)品（責(zé)任），并且他有權(quán)期望客戶已經(jīng)付款（權(quán)利）。
- 客戶必須付款（責(zé)任），并且有權(quán)得到產(chǎn)品（權(quán)利）。
- 契約雙方必須履行那些對所有契約都有效的責(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è)問題”來總結(jié)DbC，并且作為設(shè)計(jì)者要經(jīng)常問：
- 它期望的是什么？
- 它要保證的是什么？
- 它要保持的是什么？
根據(jù)Bertrand Meyer氏提出的DBC概念的描述，對于類的一個(gè)方法，都有一個(gè)前提條件以及一個(gè)后續(xù)條件，前提條件說明方法接受什么樣的參數(shù)數(shù)據(jù)等，只有前提條件得到滿足時(shí)，這個(gè)方法才能被調(diào)用；同時(shí)后續(xù)條件用來說明這個(gè)方法完成時(shí)的狀態(tài)，如果一個(gè)方法的執(zhí)行會(huì)導(dǎo)致這個(gè)方法的后續(xù)條件不成立，那么這個(gè)方法也不應(yīng)該正常返回。
現(xiàn)在把前提條件以及后續(xù)條件應(yīng)用到繼承子類中，子類方法應(yīng)該滿足：
- 前提條件不強(qiáng)于基類．
- 后續(xù)條件不弱于基類．
換句話說，通過基類的接口調(diào)用一個(gè)對象時(shí)，用戶只知道基類前提條件以及后續(xù)條件。因此繼承類不得要求用戶提供比基類方法要求的更強(qiáng)的前提條件，亦即，繼承類方法必須接受任何基類方法能接受的任何條件（參數(shù)）。同樣，繼承類必須順從基類的所有后續(xù)條件，亦即，繼承類方法的行為和輸出不得違反由基類建立起來的任何約束，不能讓用戶對繼承類方法的輸出感到困惑。
這樣，我們就有了基于契約的LSP，基于契約的LSP是LSP的一種強(qiáng)化。
參考：http://en.wikipedia.org/wiki/Design_by_contract
Acyclic Dependencies Principle (ADP) –無環(huán)依賴原則
包之間的依賴結(jié)構(gòu)必須是一個(gè)直接的無環(huán)圖形，也就是說，在依賴結(jié)構(gòu)中不允許出現(xiàn)環(huán)（循環(huán)依賴）。如果包的依賴形成了環(huán)狀結(jié)構(gòu)，怎么樣打破這種循環(huán)依賴呢？有2種方法可以打破這種循環(huán)依賴關(guān)系：第一種方法是創(chuàng)建新的包，如果A、B、C形成環(huán)路依賴，那么把這些共同類抽出來放在一個(gè)新的包D里。這樣就把C依賴A變成了C依賴D以及A依賴D，從而打破了循環(huán)依賴關(guān)系。第二種方法是使用DIP（依賴倒置原則）和ISP（接口分隔原則）設(shè)計(jì)原則。
無環(huán)依賴原則（ADP）為我們解決包之間的關(guān)系耦合問題。在設(shè)計(jì)模塊時(shí)，不能有循環(huán)依賴。
參考：http://c2.com/cgi/wiki?AcyclicDependenciesPrinciple
————————————————————————————
上面這些原則可能有些學(xué)院派，也可能太為理論，我在這里說的也比較模糊和簡單，這里只是給大家一個(gè)概貌，如果想要了解更多的東西，大家可以多google一下。
不過這些原則看上去都不難，但是要用好卻并不那么容易。要能把這些原則用得好用得精，而不教條，我的經(jīng)驗(yàn)如下：（我以為這是一個(gè)理論到應(yīng)用的過程）
- 你可以先粗淺或是表面地知道這些原則。
- 但不要急著馬上就使用。
- 在工作學(xué)習(xí)中觀察和總結(jié)別人或自己的設(shè)計(jì)。
- 再回過頭來了回顧一下這些原則，相信你會(huì)有一些自己的心得。
- 有適度地去實(shí)踐一下。
- Goto第 3步。
我相信可能還會(huì)有其實(shí)一些原則，歡迎大家提供。
it知識(shí)庫：一些軟件設(shè)計(jì)的原則，轉(zhuǎn)載需保留來源！
鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請第一時(shí)間聯(lián)系我們修改或刪除，多謝。
