【轉】一些軟件設計的原則

時間 2019-11-10

標籤一些軟件設計原則简体版

原文原文鏈接

之前本站向你們介紹過一些軟件開發的原則，好比優質代碼的十誡和Unix傳奇(下篇)中因此說的UNIX的設計原則。相信你們從中可以從中學瞭解到一些設計原理方面的知識，正如我在《再談「我是怎麼招聘程序」》中所說的，一個好的程序員一般由其操做技能、知識水平，經驗層力和能力四個方面組成。在這裏想和你們說說設計中的一些原則，我認爲這些東西屬於長期經驗總結出來的知識。這些原則，每個程序員都應該瞭解。可是請不要教條主義，在使用的時候仍是要多多考慮實際狀況。其實，下面這些原則，不僅僅只是軟件開發，能夠推廣到其它生產活動中，甚至咱們的生活中。html

Don’t Repeat Yourself (DRY)

DRY
是一個最簡單的法則，也是最容易被理解的。但它也多是最難被應用的（由於要作到這樣，咱們須要在泛型設計上作至關的努力，這並非一件容易的事）。它意味着，當咱們在兩個或多個地方的時候發現一些類似的代碼的時候，咱們須要把他們的共性抽象出來形一個惟一的新方法，而且改變現有的地方的代碼讓他們以一些合適的參數調用這個新的方法。java

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

Keep It Simple, Stupid (KISS)

KISS原則在設計上可能最被推崇的，在家裝設計，界面設計，操做設計上，複雜的東西愈來愈被衆人所BS了，而簡單的東西愈來愈被人所承認，好比這些UI的設計和咱們中國網頁（尤爲是新浪的網頁）者是負面的例子。「宜家」（IKEA）簡約、效率的家居設計、生產思路；「微軟」（Microsoft）「所見即所得」的理念；「谷歌」（Google)簡約、直接的商業風格，無一例外的遵循了「kiss」原則，也正是「kiss」原則，成就了這些看似神奇的商業經典。而蘋果公司的iPhone/iPad將這個原則實踐到了極至。web

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

參考：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應該只可以訪問如下對象中的方法:

對象O；

與O直接相關的Component Object；

由方法M建立或者實例化的對象；

做爲方法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/Principle_of_Least_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.」。意思是，好萊塢的經紀人們不但願你去聯繫他們，而是他們會在須要的時候來聯繫你。也就是說，全部的組件都是被動的，全部的組件初始化和調用都由容器負責。組件處在一個容器當中，由容器負責管理。

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

不建立對象，而是描述建立對象的方式。
在代碼中，對象與服務沒有直接聯繫，而是容器負責將這些聯繫在一塊兒。

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

好萊塢原則就是IoC（Inversion of Control）或DI（Dependency Injection
）的基礎原則。這個原則很像依賴倒置原則，依賴接口，而不是實例，可是這個原則要解決的是怎麼把這個實例傳入調用類中？你可能把其聲明成成員，你能夠經過構造函數，你能夠經過函數參數。可是
IoC可讓你經過配置文件，一個由Service Container
讀取的配置文件來產生實際配置的類。可是程序也有可能變得不易讀了，程序的性能也有可能還會降低。

參考：

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

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

內聚：一個模塊內各個元素彼此結合的緊密程度
耦合：一個軟件結構內不一樣模塊之間互連程度的度量

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

參考：

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

簡單點說，就是將一些公認的配置方式和信息做爲內部缺省的規則來使用。例如，Hibernate的映射文件，若是約定字段名和類屬性一致的話，基本上就能夠不要這個配置文件了。你的應用只須要指定不convention的信息便可，從而減小了大量convention而又不得不花時間和精力囉裏囉嗦的東東。配置文件不少時候至關的影響開發效率。

Rails 中不多有配置文件（但不是沒有，數據庫鏈接就是一個配置文件），Rails 的fans號稱期開發效率是 java 開發的 10
倍，估計就是這個緣由。Maven也使用了CoC原則，當你執行mvn
-compile命令的時候，不須要指源文件放在什麼地方，而編譯之後的class文件放置在什麼地方也沒有指定，這就是CoC原則。

參考：http://en.wikipedia.org/wiki/Convention_over_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概念的描述，對於類的一個方法，都有一個前提條件以及一個後續條件，前提條件說明方法接受什麼樣的參數數據等，只有前提條件獲得知足時，這個方法才能被調用；同時後續條件用來講明這個方法完成時的狀態，若是一個方法的執行會致使這個方法的後續條件不成立，那麼這個方法也不該該正常返回。

如今把前提條件以及後續條件應用到繼承子類中，子類方法應該知足：

前提條件不強於基類．
後續條件不弱於基類．

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

這樣，咱們就有了基於契約的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