一些軟體設計原則（轉自伯樂線上）

導讀：酷殼網的陳皓給大家介紹了軟體設計的一些原則，作者認為一個好的程式員通常由其操作技能、知識水平，經驗層力和能力四個方面組成。軟體設計的這些原則，每一個程式員都應該瞭解。相信大家從中能夠從中學瞭解到一些設計原理方面的知識。
　　 文章內容如下：

　　以前本站向大家介紹過一些軟體開發的原則，比如優質代碼的十誡和Unix傳奇(下篇)中所以說的UNIX的設計原則。相信大家從中能夠從中學瞭解到 一些設計原理方面的知識，正如我在《再談“我是怎麼招聘程式”》中所說的，一個好的程式員通常由其操作技能、知識水平，經驗層力和能力四個方面組成。在這 裡想和大家說說設計中的一些原則，我認為這些東西屬於長期經驗總結出來的知識。這些原則，每一個程式員都應該瞭解。但是請不要教條主義，在使用的時候還是 要多多考慮實際情況。

　　下面這些原則，不單單只是軟體開發，可以推廣到其它生產活動中，甚至我們的生活中。

　　Don’t Repeat Yourself(DRY)

　　DRY是一個最簡單的法則，也是最容易被理解的。但它也可能是最難被應用的（因為要做到這樣，我們需要在泛型設計上做相當的努力，這並不是一件容易 的事）。它意味著，當我們在兩個或多個地方的時候發現一些相似的代碼的時候，我們需要把他們的共性抽象出來形一個唯一的新方法，並且改變現有的地方的代碼 讓他們以一些合適的參數調用這個新的方法。

　　參考：http://en.wikipedia.org/wiki/Don%27t_repeat_yourself

　　Keep It Simple, Stupid (KISS)
　　
　　 KISS原則在設計上可能最被推崇的，在家裝設計，介面設計，操作設計上，複雜的東西越來越被眾人所BS了，而簡單的東西越來越被人所認可，比如這些UI的設計和我們中國網頁（尤其是新浪的網頁） 者是負面的例子。“宜家”（IKEA）簡約、效率的家居設計、生產思路；“微軟”（Microsoft）“所見即所得 (WYSIWYG)”的理念；“Google”（Google) 簡約、直接的商業風格，無一例外的遵循了“kiss”原則，也正是“kiss”原則，成就了這些看似神奇的商業經典。而蘋果公司的iPhone/iPad 將這個原則實踐到了極至。

　　 把一個事情搞複雜是一件簡單的事，但要把一個複雜的事變簡單，這是一件複雜的事。

　　 參考：http://en.wikipedia.org/wiki/KISS_principle

　　 Program to an interface, not an implementation

　　 這是設計模式中最根本的哲學，注重介面，而不是實現，依賴介面，而不是實現。介面是抽象是穩定的，實現則是多種多樣的。以後面我們會物件導向的SOLID原則中會提到我們的依賴倒置原則，就是這個原則的的另一種樣子。還有一條原則叫Composition over inheritance（喜歡組合而不是繼承），這兩條是那23個經典設計模式中的設計原則。

　　 Command-Query Separation (CQS)–命令-查詢分離原則

　　 查詢：當一個方法返回一個值來回應一個問題的時候，它就具有查詢的性質；
　　 命令：當一個方法要改變對象的狀態的時候，它就具有命令的性質；

　　 通常，一個方法可能是純的Command模式或者是純的Query模式，或者是兩者的混合體。在設計介面時，如果可能，應該盡量使介面單一化，保證 方法的行為嚴格的是命令或者是查詢，這樣查詢方法不會改變對象的狀態，沒有副作用，而會改變對象的狀態的方法不可能有傳回值。也就是說：如果我們要問一個 問題，那麼就不應該影響到它的答案。實際應用，要視具體情況而定，語義的清晰性和使用的簡單性之間需要權衡。將Command和Query功能合并入一個 方法，方便了客戶的使用，但是，降低了清晰性，而且，可能不便於基於斷言的程式設計並且需要一個變數來儲存查詢結果。

　　 在系統設計中，很多系統也是以這樣原則設計的，查詢的功能和命令功能的系統分離，這樣有則於系統效能，也有利於系統的安全性。

　　 參考：http://en.wikipedia.org/wiki/Command-query_separation

　　 You Ain’t Gonna Need It(YAGNI)

　　 這個原則簡而言之為——只考慮和設計必須的功能，避免過度設計。只實現目前需要的功能，在以後您需要更多功能時，可以再進行添加。
如無必要，勿增複雜性。

　　 軟體開發先是一場溝通博弈。

　　 以前本站有一篇關於過度重構的文章，這個樣本就是這個原則的反例。而，WebSphere的設計者就表示過他過度設計了這個產品。我們的程式員或是架構師在設計系統的時候，會考慮很多擴充性的東西，導致在架構與設計方面使用了大量折衷，最後導致項目失敗。這是個令人感到諷刺的教訓，因為本來希望儘可能延長項目的生命週期，結果反而縮短了生命週期。

　　 參考：http://en.wikipedia.org/wiki/You_Ain%27t_Gonna_Need_It

　　 Law of Demeter–迪米特法則

迪米特法則(Law of Demeter)，又稱“最少知識原則”（Principle of Least Knowledge），其來源於1987年荷蘭大學的一個叫做Demeter的項目。Craig Larman把Law of Demeter又稱作“不要和陌生人說話”。在《程式員修鍊之道》中講LoD的那一章叫作“解耦合與迪米特法則”。關於迪米特法則有一些很形象的比喻：

　　 如果你想讓你的狗跑的話，你會對狗狗說還是對四條狗腿說？

　　 如果你去店裡買東西，你會把錢交給店員，還是會把錢包交給店員讓他自己拿？

　　 和狗的四肢說話？讓店員自己從錢包裡拿錢？這聽起來有點荒唐，不過在我們的代碼裡這幾乎是見怪不怪的事情了。

　　 對於LoD，正式的表述如下：
對於對象‘O’中一個方法‘M'，M應該只能夠訪問以下對象中的方法：

• 1.對象O；
• 2.與O直接相關的Component Object；
• 3.由方法M建立或者執行個體化的對象；
• 4.作為方法M的參數的對象。

　　 在《Clean Code(代碼整潔之道)》一書中，有一段Apache framework中的一段違反了LoD的代碼：代碼:

final String outputDir = ctxt.getOptions().getScratchDir().getAbsolutePath();

　　 這麼長的一串對其它對象的細節，以及細節的細節，細節的細節的細節……的調用，增加了耦合，使得代碼結構複雜、僵化，難以擴充和維護。

在《重構》一書中的代碼的環味道中有一種叫做“Feature Envy”(依戀情結），形象的描述了一種違反了LoC的情況。Feature Envy就是說一個對象對其它對象的內容更有興趣，也就是說老是羨慕別的對象的成員、結構或者功能，大老遠的調用人家的東西。這樣的結構顯然是不合理的。 我們的程式應該寫得比較“害羞”。不能像前面例子中的那個不把自己當外人的店員一樣，拿過客人的錢包自己把錢拿出來。“害羞”的程式只和自己最近的朋友交 談。這種情況下應該調整程式的結構，讓那個對象自己擁有它羨慕的feature，或者使用合理的設計模式（例如Facade和Mediator）。

　　 參考：http://en.wikipedia.org/wiki/Princip...east_Knowledge

　　 物件導向的S.O.L.I.D原則

　　 一般來說這是物件導向的五大設計原則，但是，我覺得這些原則可適用於所有的軟體開發。

　　 Single Responsibility Principle (SRP)–職責單一原則

　　 關於單一職責原則，其核心的思想是：一個類，只做一件事，並把這件事做好，其只有一個引起它變化的原因。單一職 責原則可以看作是低耦合、高內聚在物件導向原則上的引申，將職責定義為引起變化的原因，以提高內聚性來減少引起變化的原因。職責過多，可能引起它變化的原 因就越多，這將導致職責依賴，相互之間就產生影響，從而極大的損傷其內聚性和耦合度。單一職責，通常意味著單一的功能，因此不要為一個模組實現過多的功能 點，以保證實體只有一個引起它變化的原因。

　　 Unix/Linux是這一原則的完美體現者。各個程式都獨立負責一個單一的事。

　　 Windows是這一原則的反面樣本。幾乎所有的程式都交織耦合在一起。

　　 Open/Closed Principle (OCP)–開閉原則

　　 關於開發封閉原則，其核心的思想是：模組是可擴充的，而不可修改的。也就是說，對擴充是開放的，而對修改是封閉的。

　　 對擴充開放，意味著有新的需求或變化時，可以對現有代碼進行擴充，以適應新的情況。

　　 對修改封閉，意味著類一旦設計完成，就可以獨立完成其工作，而不要對類進行任何修改。

　　 對於物件導向來說，需要你依賴抽象，而不是實現，23個經典設計模式中的“策略模式”就是這個實現。對於非物件導向編程，一些API需要你傳入一個 你可以擴充的函數，比如我們的C語言的qsort()允許你提供一個“比較子”，STL中的容器類的記憶體配置，ACE中的多線程的各種鎖。對於軟體方面， 瀏覽器的各種外掛程式屬於這個原則的實踐。

　　Liskov substitution principle (LSP)–裡氏代換原則

　　軟體工程大師Robert C. Martin把裡氏代換原則最終簡化為一句話：“Subtypes must be substitutable for their base types”。也就是，子類必須能夠替換成它們的基類。即：子類應該可以替換任何基類能夠出現的地方，並且經過替換以後，代碼還能正常工作。另外，不應該 在代碼中出現if/else之類對子類類型進行判斷的條件。裡氏替換原則LSP是使代碼符合開閉原則的一個重要保證。正是由於子類型的可替換性才使得父類 型的模組在無需修改的情況下就可以擴充。

　　這麼說來，似乎有點教條化，我非常建議大家看看這個原則個兩個最經典的案例——“正方形不是長方形”和“鴕鳥不是鳥”。通過這兩個案例，你會明白 《墨子小取》中說的——“娣，美人也，愛娣，非愛美人也….盜，人也；惡盜，非惡人也。”——妹妹雖然是美人，但喜歡妹妹並不代表喜歡美人。盜賊是人，但 討厭盜賊也並不代表就討厭人類。這個原則讓你考慮的不是語義上對象的間的關係，而是實際需求的環境。

　　在很多情況下，在設計初期我們類之間的關係不是很明確，LSP則給了我們一個判斷和設計類之間關係的基準：需不需要繼承，以及怎樣設計繼承關係。

　　Interface Segregation Principle (ISP)–介面隔離原則

　　介面隔離原則意思是把功能實現在介面中，而不是類中，使用多個專門的介面比使用單一的總介面要好。

　　舉個例子，我們對電腦有不同的使用方式，比如：寫作，通訊，看電影，打遊戲，上網，編程，計算，資料等，如果我們把這些功能都聲明在電腦的抽類裡 面，那麼，我們的迷你筆記型電腦，PC機，伺服器，筆記本的實作類別都要實現所有的這些介面，這就顯得太複雜了。所以，我們可以把其這些功能介面隔離開來，比如：工 作學習介面，編程開發介面，上網娛樂介面，計算和資料服務介面，這樣，我們的不同功能的電腦就可以有所選擇地繼承這些介面。

　　這個原則可以提升我們“搭積木式”的軟體開發。對於設計來說，Java中的各種Event Listener和Adapter，對於軟體開發來說，不同的使用者權限有不同的功能，不同的版本有不同的功能，都是這個原則的應用。

　　Dependency Inversion Principle(DIP)–依賴倒置原則

　　高層模組不應該依賴於低層模組的實現，而是依賴於高層抽象。

　　舉個例子，牆面的開關不應該依賴於電燈的開關實現，而是應該依賴於一個抽象的開關的標準介面，這樣，當我們擴充程式的時候，我們的開關同樣可以控制 其它不同的燈，甚至不同的電器。也就是說，電燈和其它電器繼承並實現我們的標準開關介面，而我們的開關產商就可不需要關於其要控制什麼樣的裝置，只需要關 心那個標準的開關標準。這就是依賴倒置原則。

　　這就好像瀏覽器並不依賴於後面的web伺服器，其只依賴於HTTP協議。這個原則實在是太重要了，社會的分工化，標準化都是這個設計原則的體現。

　　參考：http://en.wikipedia.org/wiki/Solid_(object-oriented_design)

　　Common Closure Principle（CCP）–共同封閉原則

　　一個包中所有的類應該對同一種類型的變化關閉。一個變化影響一個包，便影響了包中所有的類。一個更簡短的說法是：一起修改的類，應該組合在一起（同 一個包裡）。如果必須修改應用程式裡的代碼，我們希望所有的修改都發生在一個包裡（修改關閉），而不是遍布在很多包裡。CCP原則就是把因為某個同樣的原 因而需要修改的所有類組合進一個包裡。如果2個類從物理上或者從概念上聯絡得非常緊密，它們通常一起發生改變，那麼它們應該屬於同一個包。

　　CCP延伸了開閉原則（OCP）的“關閉”概念，當因為某個原因需要修改時，把需要修改的範圍限制在一個最小範圍內的包裡。

　　參考：http://c2.com/cgi/wiki?CommonClosurePrinciple

　　Common Reuse Principle (CRP)–共同重用原則

　　包的所有類被一起重用。如果你重用了其中的一個類，就重用全部。換個說法是，沒有被一起重用的類不應該被組合在一起。CRP原則協助我們決定哪些類 應該被放到同一個包裡。依賴一個包就是依賴這個包所包含的一切。當一個包發生了改變，並發布新的版本，使用這個包的所有使用者都必須在新的包環境下驗證他們 的工作，即使被他們使用的部分沒有發生任何改變。因為如果包中包含有未被使用的類，即使使用者不關心該類是否改變，但使用者還是不得不升級該包並對原來的功能 加以重新測試。

　　CCP則讓系統的維護者受益。CCP讓包儘可能大（CCP原則加入功能相關的類），CRP則讓包儘可能小（CRP原則剔除不使用的類）。它們的出發點不一樣，但不相互衝突。

　　參考：http://c2.com/cgi/wiki?CommonReusePrinciple

　　Hollywood Principle–好萊塢原則

　　好萊塢原則就是一句話——“don’t call us,we’ll call you.”。意思是，好萊塢的經紀人們不希望你去聯絡他們，而是他們會在需要的時候來聯絡你。也就是說，所有的組件都是被動的，所有的組件初始化和調用都 由容器負責。組件處在一個容器當中，由容器負責管理。

　　簡單的來講，就是由容器控製程序之間的關係，而非傳統實現中，由程式碼直接操控。這也就是所謂“控制反轉”的概念所在：

• 1.不建立對象，而是描述建立對象的方式。
• 2.在代碼中，對象與服務沒有直接聯絡，而是容器負責將這些聯絡在一起。

　　控制權由應用代碼中轉到了外部容器，控制權的轉移，是所謂反轉。

　　好萊塢原則就是IoC（Inversion of Control）或DI（Dependency Injection）的基礎原則。這個原則很像依賴倒置原則，依賴介面，而不是執行個體，但是這個原則要解決的是怎麼把這個執行個體傳入調用類中？你可能把其聲明 成成員，你可以通過建構函式，你可以通過函數參數。但是IoC可以讓你通過設定檔，一個由Service Container 讀取的設定檔來產生實際配置的類。但是程式也有可能變得不易讀了，程式的效能也有可能還會下降。

　　參考：
　　http://en.wikipedia.org/wiki/Hollywood_Principle
　　http://en.wikipedia.org/wiki/Inversion_of_Control

　　High Cohesion & Low/Loose coupling & –高內聚，低耦合

　　這個原則是UNIX作業系統設計的經典原則，把模組間的耦合降到最低，而努力讓一個模組做到精益求精。

• 內聚：一個模組內各個元素彼此結合的緊密程度
• 耦合：一個軟體結構內不同模組之間互連程度的度量

　　內聚意味著重用和獨立，耦合意味著多米諾效應牽一髮動全身。

　　參考：
　　http://en.wikipedia.org/wiki/Coupling_(computer_science)
　　http://en.wikipedia.org/wiki/Cohesion_(computer_science)

　　Convention over Configuration（CoC）–慣例優於配置原則

　　簡單點說，就是將一些公認的配置方式和資訊作為內部預設的規則來使用。例如，Hibernate的對應檔，如果約定欄位名和類屬性一致的話，基本 上就可以不要這個設定檔了。你的應用只需要指定不convention的資訊即可，從而減少了大量convention而又不得不花時間和精力囉裡囉嗦 的東東。設定檔很多時候相當的影響開發效率。

　　Rails中很少有設定檔（但不是沒有，資料庫連接就是一個設定檔），Rails的fans號稱期開發效率是java開發的10倍，估計就是這 個原因。Maven也使用了CoC原則，當你執行mvn -compile命令的時候，不需要指源檔案放在什麼地方，而編譯以後的class檔案放置在什麼地方也沒有指定，這就是CoC原則。

　　參考：http://en.wikipedia.org/wiki/Convent..._Configuration

　　Separation of Concerns (SoC)–關注點分離

　　SoC是電腦科學中最重要的努力目標之一。這個原則，就是在軟體開發中，通過各種手段，將問題的各個關注點分開。如果一個問題能分解為獨立且較小 的問題，就是相對較易解決的。問題太過於複雜，要解決問題需要關注的點太多，而程式員的能力是有限的，不能同時關注於問題的各個方面。正如程式員的記憶力 相對於電腦知識來說那麼有限一樣，程式員解決問題的能力相對於要解決的問題的複雜性也是一樣的非常有限。在我們分析問題的時候，如果我們把所有的東西混 在一起討論，那麼就只會有一個結果——亂。

　　我記得在上一家公司有一個項目，討論就討論了1年多，項目本來不複雜，但是沒有使用SoC，全部的東西混為一談，再加上一堆程式員注入了各種不同的觀點和想法，整個項目一下子就失控了。最後，本來一個1年的項目做了3年。

　　實現關注點分離的方法主要有兩種，一種是標準化，另一種是抽象與封裝。標準化就是制定一套標準，讓使用者都遵守它，將人們的行為統一起來，這樣使用 標準的人就不用擔心別人會有很多種不同的實現，使自己的程式不能和別人的配合。Java EE就是一個標準的大集合。每個開發人員只需要關注於標準本身和他所在做的事情就行了。就像是開發鏍絲釘的人只專註於開發鏍絲釘就行了，而不用關注鏍帽是怎 麼生產的，反正鏍帽和鏍絲釘按標來就一定能合得上。不斷地把程式的某些部分抽像差封裝起來，也是實現關注點分離的好方法。一旦一個函數被抽像出來並實現 了，那麼使用函數的人就不用關心這個函數是如何?的，同樣的，一旦一個類被抽像並實現了，類的使用者也不用再關注於這個類的內部是如何?的。諸如組 件，分層，面向服務，等等這些概念都是在不同的層次上做抽像和封裝，以使得使用者不用關心它的內部實現細節。
說白了還是“高內聚，低耦合”。

　　參考：http://sulong.me/archives/99

　　Design by Contract (DbC)–契約式設計

　　DbC的核心思想是對軟體系統中的元素之間相互合作以及“責任”與“義務”的比喻。這種比喻從商務工作中“客戶”與“供應商”達成“契約”而得來。例如：
供應商必須提供某種產品（責任），並且他有權期望客戶已經付款（權利）。
客戶必須付款（責任），並且有權得到產品（權利）。

　　契約雙方必須履行那些對所有契約都有效責任，如法律和規定等。

　　同樣的，如果在程式設計中一個模組提供了某種功能，那麼它要：
期望所有調用它的客戶模組都保證一定的進入條件：這就是模組的先驗條件（客戶的義務和供應商的權利，這樣它就不用去處理不滿足先驗條件的情況）。

　　保證退出時給出特定的屬性：這就是模組的後驗條件——（供應商的義務，顯然也是客戶的權利）。

　　在進入時假定，並在退出時保持一些特定的屬性：不變式。

　　契約就是這些權利和義務的正式形式。我們可以用“三個問題”來總結DbC，並且作為設計者要經常問：

• 它期望的是什嗎？
• 它要保證的是什嗎？
• 它要保持的是什嗎？

　　根據Bertrand Meyer氏提出的DBC概念的描述，對於類的一個方法，都有一個前提條件以及一個後續條件，前提條件說明方法接受什麼樣的參數資料等，只有前提條件得到 滿足時，這個方法才能被調用；同時後續條件用來說明這個方法完成時的狀態，如果一個方法的執行會導致這個方法的後續條件不成立，那麼這個方法也不應該正常 返回。

　　現在把前提條件以及後續條件應用到繼承子類中，子類方法應該滿足：

• 1.前提條件不強於基類．
• 2.後續條件不弱於基類．

　　換句話說，通過基類的介面調用一個對象時，使用者只知道基類前提條件以及後續條件。因此繼承類不得要求使用者提供比基類方法要求的更強的前提條件，亦 即，繼承類方法必須接受任何基類方法能接受的任何條件（參數）。同樣，繼承類必須順從基類的所有後續條件，亦即，繼承類方法的行為和輸出不得違反由基類建 立起來的任何約束，不能讓使用者對繼承類方法的輸出感到困惑。

　　這樣，我們就有了基於契約的LSP，基於契約的LSP是LSP的一種強化。

　　參考：http://en.wikipedia.org/wiki/Design_by_contract

　　Acyclic Dependencies Principle (ADP)–無環依賴原則

　　包之間的依賴結構必須是一個直接的無環圖形，也就是說，在依賴結構中不允許出現環（循環相依性）。如果包的依賴形成了環狀結構，怎麼樣打破這種迴圈依 賴呢？有2種方法可以打破這種循環相依性關係：第一種方法是建立新的包，如果A、B、C形成環路依賴，那麼把這些共同類抽出來放在一個新的包D裡。這樣就把 C依賴A變成了C依賴D以及A依賴D，從而打破了循環相依性關係。第二種方法是使用DIP（依賴倒置原則）和ISP（介面分隔原則）設計原則。

　　無環依賴原則（ADP）為我們解決包之間的關係耦合問題。在設計模組時，不能有循環相依性。

　　參考：http://c2.com/cgi/wiki?AcyclicDependenciesPrinciple

　　上面這些原則可能有些學院派，也可能太為理論，我在這裡說的也比較模糊和簡單，這裡只是給大家一個概貌，如果想要瞭解更多的東西，大家可以多google一下。

　　不過這些原則看上去都不難，但是要用好卻並不那麼容易。要能把這些原則用得好用得精，而不教條，我的經驗如下：（我以為這是一個理論到應用的過程）

• 1.你可以先粗淺或是表面地知道這些原則。
• 2.但不要急著馬上就使用。
• 3.在工作學習中觀察和總結別人或自己的設計。
• 4.再回過頭來了回顧一下這些原則，相信你會有一些自己的心得。
• 5.有適度地去實踐一下。
• 6.Goto第 3步。

　　我相信可能還會有其實一些原則，歡迎大家提供。