設計模式的六大原則（轉）

時間 2019-11-09

標籤設計模式六大原則简体版

原文原文鏈接

轉發地址：http://www.cnblogs.com/firstdream/p/7101289.htmlhtml

單一職責原則

定義

不要存在多於一個致使類變動的緣由。通俗的說，即一個類只負責一項職責。java

問題由來

類T負責兩個不一樣的職責：職責P1，職責P2。當因爲職責P1需求發生改變而須要修改類T時，有可能會致使本來運行正常的職責P2功能發生故障。git

解決方案

遵循單一職責原則。分別創建兩個類T一、T2，使T1完成職責P1功能，T2完成職責P2功能。這樣，當修改類T1時，不會使職責P2發生故障風險；同理，當修改T2時，也不會使職責P1發生故障風險。程序員

說到單一職責原則，不少人都會不屑一顧。由於它太簡單了。稍有經驗的程序員即便歷來沒有讀過設計模式、歷來沒有據說過單一職責原則，在設計軟件時也會自覺的遵照這一重要原則，由於這是常識。在軟件編程中，誰也不但願由於修改了一個功能致使其餘的功能發生故障。而避免出現這一問題的方法即是遵循單一職責原則。雖然單一職責原則如此簡單，而且被認爲是常識，可是即使是經驗豐富的程序員寫出的程序，也會有違背這一原則的代碼存在。爲何會出現這種現象呢？由於有職責擴散。所謂職責擴散，就是由於某種緣由，職責P被分化爲粒度更細的職責P1和P2。web

好比：類T只負責一個職責P，這樣設計是符合單一職責原則的。後來因爲某種緣由，也許是需求變動了，也許是程序的設計者境界提升了，須要將職責P細分爲粒度更細的職責P1，P2，這時若是要使程序遵循單一職責原則，須要將類T也分解爲兩個類T1和T2，分別負責P一、P2兩個職責。可是在程序已經寫好的狀況下，這樣作簡直太費時間了。因此，簡單的修改類T，用它來負責兩個職責是一個比較不錯的選擇，雖然這樣作有悖於單一職責原則。（這樣作的風險在於職責擴散的不肯定性，由於咱們不會想到這個職責P，在將來可能會擴散爲P1，P2，P3，P4……Pn。因此記住，在職責擴散到咱們沒法控制的程度以前，馬上對代碼進行重構。）編程

舉例說明，用一個類描述動物呼吸這個場景：後端

class Animal{ public void breathe(String animal){ System.out.println(animal+"呼吸空氣"); } } public class Client{ public static void main(String[] args){ Animal animal = new Animal(); animal.breathe("牛"); animal.breathe("羊"); animal.breathe("豬"); } }

運行結果：設計模式

牛呼吸空氣  
羊呼吸空氣  
豬呼吸空氣

程序上線後，發現問題了，並非全部的動物都呼吸空氣的，好比魚就是呼吸水的。修改時若是遵循單一職責原則，須要將Animal類細分爲陸生動物類Terrestrial，水生動物Aquatic，代碼以下：網絡

class Terrestrial{ public void breathe(String animal){ System.out.println(animal+"呼吸空氣"); } } class Aquatic{ public void breathe(String animal){ System.out.println(animal+"呼吸水"); } } public class Client{ public static void main(String[] args){ Terrestrial terrestrial = new Terrestrial(); terrestrial.breathe("牛"); terrestrial.breathe("羊"); terrestrial.breathe("豬"); Aquatic aquatic = new Aquatic(); aquatic.breathe("魚"); } }

運行結果：架構

牛呼吸空氣  
羊呼吸空氣  
豬呼吸空氣  
魚呼吸水

咱們會發現若是這樣修改花銷是很大的，除了將原來的類分解以外，還須要修改客戶端。而直接修改類Animal來達成目的雖然違背了單一職責原則，但花銷卻小的多，代碼以下：

class Animal{ public void breathe(String animal){ if("魚".equals(animal)){ System.out.println(animal+"呼吸水"); }else{ System.out.println(animal+"呼吸空氣"); } } } public class Client{ public static void main(String[] args){ Animal animal = new Animal(); animal.breathe("牛"); animal.breathe("羊"); animal.breathe("豬"); animal.breathe("魚"); } }

能夠看到，這種修改方式要簡單的多。可是卻存在着隱患：有一天須要將魚分爲呼吸淡水的魚和呼吸海水的魚，則又須要修改Animal類的breathe方法，而對原有代碼的修改會對調用"豬""牛""羊"等相關功能帶來風險，也許某一天你會發現程序運行的結果變爲"牛呼吸水"了。這種修改方式直接在代碼級別上違背了單一職責原則，雖然修改起來最簡單，但隱患倒是最大的。還有一種修改方式：

class Animal{ public void breathe(String animal){ System.out.println(animal+"呼吸空氣"); } public void breathe2(String animal){ System.out.println(animal+"呼吸水"); } } public class Client{ public static void main(String[] args){ Animal animal = new Animal(); animal.breathe("牛"); animal.breathe("羊"); animal.breathe("豬"); animal.breathe2("魚"); } }

能夠看到，這種修改方式沒有改動原來的方法，而是在類中新加了一個方法，這樣雖然也違背了單一職責原則，但在方法級別上倒是符合單一職責原則的，由於它並無動原來方法的代碼。這三種方式各有優缺點，那麼在實際編程中，採用哪一中呢？其實這真的比較難說，須要根據實際狀況來肯定。個人原則是：只有邏輯足夠簡單，才能夠在代碼級別上違反單一職責原則；只有類中方法數量足夠少，才能夠在方法級別上違反單一職責原則；

例如本文所舉的這個例子，它太簡單了，它只有一個方法，因此，不管是在代碼級別上違反單一職責原則，仍是在方法級別上違反，都不會形成太大的影響。實際應用中的類都要複雜的多，一旦發生職責擴散而須要修改類時，除非這個類自己很是簡單，不然仍是遵循單一職責原則的好。

遵循單一職責原的優勢有：

能夠下降類的複雜度，一個類只負責一項職責，其邏輯確定要比負責多項職責簡單的多；
提升類的可讀性，提升系統的可維護性；
變動引發的風險下降，變動是必然的，若是單一職責原則遵照的好，當修改一個功能時，能夠顯著下降對其餘功能的影響。

須要說明的一點是單一職責原則不僅是面向對象編程思想所特有的，只要是模塊化的程序設計，都適用單一職責原則。

陳述：

就一個類而言，應該只有一個致使其變化的緣由

分析： 一個職責就是一個變化的軸線。一個類若是承擔的職責過多，就等於將這些職責耦合在一塊兒。一個職責的變化可能會虛弱或者抑止這個類完成其它職責的能力。

多職責將致使脆弱性的臭味。

示例1：

Rectangle類具備兩個職責：計算矩形面積的數學模型將矩形在一個圖形設備上描述出來

Rectangle類違反了SRP，具備兩個職能——計算面積和繪製矩形這種對SRP的違反將致使兩個方面的問題：包含沒必要要的代碼一個應用可能但願使用Retangle類計算矩形的面積，可是卻被迫將繪製矩形相關的代碼也包含進來一些邏輯上毫無關聯的緣由可能致使應用失敗若是GraphicalApplication的需求發生了變化，從而對Rectangle類進行了修改。可是這樣的變化竟然會要求咱們從新構建、測試以及部署ComputationalGeometryApplication，不然其將莫名其妙的失敗。

修改後的設計以下：

示例2： 一個Modem的接口：

[cpp] view plain copy print ?

Class Modem{
public:
virtual void dail(char* pno)=0;
virtual void hangup( ) =0;
virtual void send(char c) =0;
virtual void recv( ) =0;
};

Class Modem{
	public: 
	virtual void dail(char* pno)=0;
	virtual void hangup( ) =0;
	virtual void send(char c) =0;
	virtual void recv( ) =0;
};

Modem類（可能）有兩個職責：

撥號
通訊

--什麼是職責？ 職責是「變化的緣由」。

--上面的例子可能存在兩種變化的方式：

鏈接和通訊可能獨立變化

在這種狀況下，應該將職責分開。例如，應用的變化致使了鏈接部分方法的簽名（signature）發生了變化，那麼使用數據鏈接的部分也須要從新編譯、部署，這會至關麻煩，使得設計僵化。

鏈接和通訊同時變化

這種狀況下，沒必要將職責分開。反而分離可能致使「沒必要要的複雜性」的臭味

修改後的設計以下：

有一點須要注意：在ModemImplementation中實際仍是集合了兩個職責。這是咱們不但願的，可是有時候倒是必須的。可是咱們注意到，對於應用的其它部分，經過接口的分離咱們已經實現了職責的分離。 ModemImplementation已經不被其它任何程序所依賴。除了main之外，其餘全部程序都不須要知道這個函數的存在。

質疑: Q:ModemImplementation有兩個緣由引發變化?應採用以下類圖。 A:咱們面向接口編程,對外公佈的是接口而非實現類。若是真要實現類的單一職責，就必須使用組合模式，會引發類間耦合太重、類的數量增長等問題，人爲增長設計的複雜性。

單一職責原則的好處：

類的複雜性下降，實現什麼職責都有清晰明確的定義；
可讀性提升，複雜性下降，可維性提升；
變動引發的風險下降，變動是必不可少的，若是接口的單一職責作得好，一個接口修改只對相應的實現類有影

響，對其餘接口無影響，對系統的擴展性、維護性有較大的幫助。

常見錯誤提醒：

持久化與業務規則的耦合。

Employee類包含了業務規則和對持久化的控制。業務規則常常變化，而持久化方法卻通常不變，並且變化緣由也徹底不一樣。將這兩個職責耦合在一塊兒，將致使每次由於業務規則變化調整Employee類時，全部持久化部分的代碼也要跟着變化

小結：

若是一個類承擔的職責過多，就等於把這些職責耦合在一塊兒，一個職責的變化可能會削弱或者抑制這個類完成其餘職責的能力。這種耦合會致使脆弱的設計，當變化發生時，設計會遭受到意想不到的破壞。
咱們會天然地把職責結合在一塊兒。若是能想到多於一個動機去改變一個類，那麼這個類就具備多於一個的職責，就應該考慮類的職責分離。
軟件設計真正要作的許多內容，就是發現職責並把那些職責相互分離。
SRP是全部原則中最簡單、也是最難運用的。其他原則會以這樣或那樣的方式回到這個問題上。
單一職責原則提出了一個編寫程序的標準，用「職責」或「變化緣由」來衡量接口類或類設計得是否好，但「職責」和「變化緣由」都是不可度量的，因項目而異，依環境而異。
單一職責原則很難在項目中獲得體現。考慮工期、成本、人員技術水平、硬件狀況甚至項目以外的因素。
建議：接口必定作到單一職責，類的設計儘可能作到只有一個緣由引發變化。

最近在實踐微服務化過程當中，對其「單一職責」原則深有體會。那麼只有微服務化才能夠單一職責，才能夠解耦嗎？答案是否認的。

單一職責原則是這樣定義的：單一的功能，而且徹底封裝起來。

咱們作後端Java開發的，應該最熟悉的就是標準的3層架構了，尤爲是使用Spring.io體系的：Controller、Service、Dao/Repository。爲何要分層？就是爲了保證單一職責，數據模型的事情交給Controller，業務邏輯的事情交給Service，和數據打交道的事情就交給Dao/Repository。有時候或者有些人會分層分的更多，4層，5層，我本身也這樣幹過，說白了也是爲了保證單一職責，3層不能知足單一職責了，耦合度高了，就分。

咱們都知道一個webapp在通過必定時間的開發後，就慘不忍睹，即使是有標準的分層，頁面或模板文件一大堆，最初的很清晰的3層標準架構也變味了，Controller，Service，Dao/Repository各層之間、Service之間、Dao/Repository之間互相調用，一團亂麻。這個時候沒改一行代碼都有可能一個老鼠害了一鍋湯，bug就如同螞蟻洞。

這些問題最後就形成：

可擴展性靈活性差，出現性能問題
業務變動和開發困難，維護成本很高，交付時間長
迴歸測試量很大
...

爲了解決這些問題，就須要時時刻刻清楚的記住「單一職責」，單一職責能夠用到軟件開發的任何地方。

應該說職責分離來解耦是最經常使用最有效的架構方法，這可以很大限度的簡化一切。

下面就從軟件開發、設計、架構，以及重構/演進/進化，從小到大幾個方面來講說單一職責：

類方法/函數

這應該是最小的能體現單一職責的程序單元了。最熟悉的最典型的莫過於Helper/Utils類方法了，但這種類方法的特徵很明顯，也很容易遵循單一職責，99%以上的開發人員均可以作到。但不只僅這樣的類方法要遵循單一職責原則，每個類方法都應該遵循單一職責原則，尤爲是一些處理業務邏輯的類方法更要遵循單一職責原則，處理業務的類方法一般要配合類的單一職責原則進行，下節中討論。

所以，這也是爲何不少Team Leader要求類方法代碼行數保持在20行左右，其實就是爲了保證單一職責，20行左右是一個經驗粗略數字，固然，10行或者30行來完成類方法也是能夠的。大部分單一職責的類方法用20行左右的代碼就夠了，若是超過20行就要考慮是否保證了單一職責了。那咱們在迭代重構的過程當中就要考慮拆分這樣的類方法來保證單一職責。

類方法的單一職責是最單純的，很具體的，不摻雜任何額外信息，只關心輸入、輸出、和職責；必定要明確地定義類方法的職責，保證在迭代中不被錯誤的擴展，不被調用者錯誤地使用。

類/函數文件

要用面向對象的設計方法，單一職責原則來定義類。開發人員必定要很好地理解「單一職責原則」，具備面向對象的抽象思惟能力。

當在迭代中一個類過於龐大或者快速膨脹，說明已經有壞味道了，這時候就須要考慮用單一職責原則或者面向對象的分析方法來重構和從新定義類了，一般就是要抽象和拆分類，不然未來會變成一個方法容器。

把類比做一我的，她的職責就是完成本身職責範圍內的事情，若是她什麼事情都管，就叫多管閒事，能夠想象她多管閒事的後果，會攪得雞犬不寧。一樣，類也是，類若是多管閒事，那會攪得整個應用不穩定，漏洞百出，還很難修復。因此說定義一個類，要明確這個類的職責。使用面向對象的分析和設計方法，能很好地準肯定義一個類的職責範圍，一般會用到封裝、繼承、多態和抽象等設計方法。

包結構/文件夾

分層就是最經常使用的架構方法之一，分層具體體如今分包和分類，就是分門別類的意思。俗話說，物以類聚，人以羣分。

包結構在單一職責原則上是類的補充，職責範圍進一步擴大。若是把一個類叫作一我的，那麼包就是一個最小單位的團隊，職責就是負責一類特定事情。如何分包呢？那就要用到分類學的知識了，要以什麼特徵來分，可能不只僅只有一種特徵，好比，先用公司域名來作基礎包名，這裏叫一級包名；而後再用一個特定的有意義的標識做爲二級子包名；以後按分層（web,dao,service等等）方法作三級包名，也能夠先按照業務再按分層。例如：

域名：tietang.wang
有個項目叫：social
那麼我能夠這樣分：
wang.tietang
    - social
        - web
        - service
        - dao
        - commons

也能夠這樣：

wang.tietang
    - commons
    - user
        - web
        - service
        - dao
    - relation
        - web
        - service
        - dao

多工程/module

一般以多maven module或者gradle 多module形式存在，來保證單一職責。

當業務量尚未達到服務拆分的火候，一般在一個APP發展的太龐大時或者在工程建設初期時，須要規範和整理項目結構。這個時候須要多工程從文件系統上隔離，經過module依賴來集成。須要注意的是這樣的架構或拆分不是隨意的，要以單一職責原則來拆分，更具體一點就是要根據業務、技術框架功能等特性來拆分。

好比，按技術組件拆分，一般會有一些技術組件，能夠把她放到commons module，若是有多種類型的技術組件，就拆分爲commons module的子module；也能夠直接將這些技術組件拆分爲獨立的工程，存在於獨立的git/svn倉庫，獨立管理，專人負責，其餘哪些module須要就依賴她。那拆分的這些技術組件的每個應該遵循單一職責原則，例如數據分片的框架、NIO基礎網絡框架等等。

好比，按業務拆分，例若有用戶、訂單、商品、支付，那麼就按照這些業務拆分爲子module，每個子module就只負責本身的業務邏輯，也遵循單一職責。

那每一個module的職責範圍又比類和包更大，這個時候職責也更模糊，有時候很難把握，對於技術組件可能相對清晰，而業務module就要熟悉業務，明確業務邊界。

多module拆分後也是爲未來服務化埋下伏筆，同時在物理文件系統比較清晰了，那在依賴管理上也要掌握好保持清晰的依賴邏輯，把握好單一職責原則。

微服務/可部署單元

微服務，從運行時隔離，但業務量發展到必定時候，從單體或者多module工程拆分或演化出來，可獨立打包可獨立部署並複合單一原則的application，固然了微服務所體現的價值不只僅是隔離和獨立部署，還有不少這裏能夠參考單體應用與微服務優缺點辨析。單一職責在微服務中的價值是最重要的，包含了app層面和開發app的團隊層面，微服務的大部分優勢均可以圍繞單一職責來展開。

團隊

先引用《韓非子·揚權》中的一段文字：

夫物者有所宜，材者有所施，各處其宜，故上下無爲。使雞司夜，令狸執鼠，皆用其能，上乃無事。上有所長，事乃不方。矜而好能，下之所欺：辯惠好生，下因其材。上下易用，國故不治。

各得其所，各司其職。因此，團隊也要遵循單一職責原則，這樣才能很好地管理團隊成員的時間，提升效率。一我的專一作一件事情的效率遠高於同時關注多件事情。一樣一我的一直管理和維護同一份代碼要比多人同時維護多份代碼的效率高不少。每個人都有本身的個性，他有本身的擅長，讓每個人專一本身擅長的事情，那確定事半功倍，整個團隊績效確定也很突出。

總之，引用古文名句說明了全部：

物以類聚，人以羣分。
天下之事，分合交替，分久必合，合久必分！
使雞司夜，令狸執鼠，皆用其能，上乃無事。

參考

爲何單一職責原則(SRP)是最難運用的單一職責原則(SRP)已經幾乎是每個程序員都知道的設計原則。最先由Robert C. Martin在<<敏捷軟件開發 — 原則、模式與實踐>>中正式提出。書中做者在結論中提到: SRP是全部設計原則最簡單的，但也是最難運用的。（中文翻譯有之一，略去了)
現實工做中，關於一個類是否符合SRP，或者是否有必要符合SRP的討論是常常發生的。爭論的關鍵在於職責的定義，但我理解SRP真正的核心是關注於變化。這並非個人新看法，全是來自Martin大叔的解釋：

首先職責的定義是: 引發變化的緣由，不是由分類所決定的。若是存在相對的變化，纔要考慮分離。
其次，關於引發變化的因素，不要空想。必定確信有變化的可能，纔會加以考慮。

他的提醒是很是中肯的。實踐中正是經常基於功能的分類來定義職責的。

舉個例子。假如咱們要開發一個學校的教職員工管理系統。須要定義一個教師員工的類(炒菜的師傅先就不考慮了)，考慮到老師和班主任兩個角色，一般會認爲他有兩類職責: . 教師 (班主任極可能會帶課) . 班級的管理 (組織班委，整治一下早戀之類的)
這時你拿着設計到了一個寄宿學校，校長可能會告訴你，他們這裏的教師會輪流值班，兼作保育員，照看住校的學生。又是一個新的職責，怎麼辦?
若是遵照單一職責的原則，咱們應該增長一個接口:

果然要如此嗎? 注意，若是是在通常的學校，保育員不是老師的本職工做，可在這所寄宿學校裏，倒是教師的本職工做，是和老師一塊兒變化的。校長的反饋是:

「咱們學校的教師必須擔任保育工做，我並不認爲這會是什麼新職責。做爲教師，要麼接受，要麼離開。至於班主任工做，確實仍是其特殊的地方，否則也不會給擔任班主任的老師多一點津貼了。」。

請再體會一下，關於保育員職責的討論。若是兩個職責/角色不是同時變化的，才考慮分離。若是肯定同時變化，就沒有必要分離。除非有一天，某個勞動部門到該寄宿學校檢查，認爲他們這樣不符合某個法律規定，強制規定老師能夠選擇是否擔當保育員。如此一來，兩個職責就又變成獨立變化的了，就能夠考慮分離職責。

再進一步，若是是針對一個只有一個支教教師的小學，極爲偏僻。這裏的校長會告訴你:

」這個學校裏的每個教師，惟一的一個，既是校長，也是老師。我不認爲還須要明確班主任作什麼，教師作什麼，在這裏，只要學生須要的都要作。而且這裏很窮，五年內都不見得再有新老師來。」。

這個感人的故事告訴咱們，在這所學校裏，他不在了，這所學校也就不在了，徹底沒有什麼相對的變化，也沒有什麼能夠確認的變化。因此在這裏的管理系統裏，教職員工只有一個實例類.

里氏替換原則

確定有很多人跟我剛看到這項原則的時候同樣，對這個原則的名字充滿疑惑。其實緣由就是這項原則最先是在1988年，由麻省理工學院的一位姓裏的女士（Barbara Liskov）提出來的。

定義 1

若是對每個類型爲 T1的對象 o1，都有類型爲 T2 的對象o2，使得以 T1定義的全部程序 P 在全部的對象 o1 都代換成 o2 時，程序 P 的行爲沒有發生變化，那麼類型 T2 是類型 T1 的子類型。

定義 2

全部引用基類的地方必須能透明地使用其子類的對象。

問題由來

有一功能P1，由類A完成。現須要將功能P1進行擴展，擴展後的功能爲P，其中P由原有功能P1與新功能P2組成。新功能P由類A的子類B來完成，則子類B在完成新功能P2的同時，有可能會致使原有功能P1發生故障。

解決方案

當使用繼承時，遵循里氏替換原則。類B繼承類A時，除添加新的方法完成新增功能P2外，儘可能不要重寫父類A的方法，也儘可能不要重載父類A的方法。

繼承包含這樣一層含義：父類中凡是已經實現好的方法（相對於抽象方法而言），其實是在設定一系列的規範和契約，雖然它不強制要求全部的子類必須聽從這些契約，可是若是子類對這些非抽象方法任意修改，就會對整個繼承體系形成破壞。而里氏替換原則就是表達了這一層含義。

繼承做爲面向對象三大特性之一，在給程序設計帶來巨大便利的同時，也帶來了弊端。好比使用繼承會給程序帶來侵入性，程序的可移植性下降，增長了對象間的耦合性，若是一個類被其餘的類所繼承，則當這個類須要修改時，必須考慮到全部的子類，而且父類修改後，全部涉及到子類的功能都有可能會產生故障。

舉例說明繼承的風險，咱們須要完成一個兩數相減的功能，由類A來負責。

class A{ public int func1(int a, int b){ return a-b; } } public class Client{ public static void main(String[] args){ A a = new A(); System.out.println("100-50="+a.func1(100, 50)); System.out.println("100-80="+a.func1(100, 80)); } }

運行結果：

100-50=50 100-80=20

後來，咱們須要增長一個新的功能：完成兩數相加，而後再與100求和，由類B來負責。即類B須要完成兩個功能：

兩數相減。
兩數相加，而後再加100。

因爲類A已經實現了第一個功能，因此類B繼承類A後，只須要再完成第二個功能就能夠了，代碼以下：

class B extends A{ public int func1(int a, int b){ return a+b; } public int func2(int a, int b){ return func1(a,b)+100; } } public class Client{ public static void main(String[] args){ B b = new B(); System.out.println("100-50="+b.func1(100, 50)); System.out.println("100-80="+b.func1(100, 80)); System.out.println("100+20+100="+b.func2(100, 20)); } }

類B完成後，運行結果：

100-50=150  
100-80=180  
100+20+100=220

咱們發現本來運行正常的相減功能發生了錯誤。緣由就是類B在給方法起名時無心中重寫了父類的方法，形成全部運行相減功能的代碼所有調用了類B重寫後的方法，形成本來運行正常的功能出現了錯誤。在本例中，引用基類A完成的功能，換成子類B以後，發生了異常。在實際編程中，咱們經常會經過重寫父類的方法來完成新的功能，這樣寫起來雖然簡單，可是整個繼承體系的可複用性會比較差，特別是運用多態比較頻繁時，程序運行出錯的概率很是大。若是非要重寫父類的方法，比較通用的作法是：原來的父類和子類都繼承一個更通俗的基類，原有的繼承關係去掉，採用依賴、聚合，組合等關係代替。

里氏替換原則通俗的來說就是：子類能夠擴展父類的功能，但不能改變父類原有的功能。它包含如下4層含義：

子類能夠實現父類的抽象方法，但不能覆蓋父類的非抽象方法。
子類中能夠增長本身特有的方法。
當子類的方法重載父類的方法時，方法的前置條件（即方法的形參）要比父類方法的輸入參數更寬鬆。
當子類的方法實現父類的抽象方法時，方法的後置條件（即方法的返回值）要比父類更嚴格。

看上去很難以想象，由於咱們會發如今本身編程中經常會違反里氏替換原則，程序照樣跑的好好的。因此你們都會產生這樣的疑問，假如我非要不遵循里氏替換原則會有什麼後果？

後果就是：你寫的代碼出問題的概率將會大大增長。

依賴倒置原則

定義

高層模塊不該該依賴低層模塊，兩者都應該依賴其抽象；抽象不該該依賴細節；細節應該依賴抽象。

問題由來

類A直接依賴類B，假如要將類A改成依賴類C，則必須經過修改類A的代碼來達成。這種場景下，類A通常是高層模塊，負責複雜的業務邏輯；類B和類C是低層模塊，負責基本的原子操做；假如修改類A，會給程序帶來沒必要要的風險。

解決方案

將類A修改成依賴接口I，類B和類C各自實現接口I，類A經過接口I間接與類B或者類C發生聯繫，則會大大下降修改類A的概率。

依賴倒置原則基於這樣一個事實：相對於細節的多變性，抽象的東西要穩定的多。以抽象爲基礎搭建起來的架構比以細節爲基礎搭建起來的架構要穩定的多。在java中，抽象指的是接口或者抽象類，細節就是具體的實現類，使用接口或者抽象類的目的是制定好規範和契約，而不去涉及任何具體的操做，把展示細節的任務交給他們的實現類去完成。

依賴倒置原則的核心思想是面向接口編程，咱們依舊用一個例子來講明面向接口編程比相對於面向實現編程好在什麼地方。場景是這樣的，母親給孩子講故事，只要給她一本書，她就能夠照着書給孩子講故事了。代碼以下：

class Book{ public String getContent(){ return "好久好久之前有一個阿拉伯的故事……"; } } class Mother{ public void narrate(Book book){ System.out.println("媽媽開始講故事"); System.out.println(book.getContent()); } } public class Client{ public static void main(String[] args){ Mother mother = new Mother(); mother.narrate(new Book()); } }

運行結果：

媽媽開始講故事  
好久好久之前有一個阿拉伯的故事……

運行良好，假若有一天，需求變成這樣：不是給書而是給一份報紙，讓這位母親講一下報紙上的故事，報紙的代碼以下：

class Newspaper{ public String getContent(){ return "林書豪38+7領導尼克斯擊敗湖人……"; } }

這位母親卻辦不到，由於她竟然不會讀報紙上的故事，這太荒唐了，只是將書換成報紙，竟然必需要修改Mother才能讀。假如之後需求換成雜誌呢？換成網頁呢？還要不斷地修改Mother，這顯然不是好的設計。緣由就是Mother與Book之間的耦合性過高了，必須下降他們之間的耦合度才行。

咱們引入一個抽象的接口IReader。讀物，只要是帶字的都屬於讀物：

interface IReader{ public String getContent(); }

Mother類與接口IReader發生依賴關係，而Book和Newspaper都屬於讀物的範疇，他們各自都去實現IReader接口，這樣就符合依賴倒置原則了，代碼修改成：

class Newspaper implements IReader { public String getContent(){ return "林書豪17+9助尼克斯擊敗老鷹……"; } } class Book implements IReader{ public String getContent(){ return "好久好久之前有一個阿拉伯的故事……"; } } class Mother{ public void narrate(IReader reader){ System.out.println("媽媽開始講故事"); System.out.println(reader.getContent()); } } public class Client{ public static void main(String[] args){ Mother mother = new Mother(); mother.narrate(new Book()); mother.narrate(new Newspaper()); } }

運行結果：

媽媽開始講故事  
好久好久之前有一個阿拉伯的故事……  
媽媽開始講故事  
林書豪17+9助尼克斯擊敗老鷹……

這樣修改後，不管之後怎樣擴展Client類，都不須要再修改Mother類了。這只是一個簡單的例子，實際狀況中，表明高層模塊的Mother類將負責完成主要的業務邏輯，一旦須要對它進行修改，引入錯誤的風險極大。因此遵循依賴倒置原則能夠下降類之間的耦合性，提升系統的穩定性，下降修改程序形成的風險。

採用依賴倒置原則給多人並行開發帶來了極大的便利，好比上例中，本來Mother類與Book類直接耦合時，Mother類必須等Book類編碼完成後才能夠進行編碼，由於Mother類依賴於Book類。修改後的程序則能夠同時開工，互不影響，由於Mother與Book類一點關係也沒有。參與協做開發的人越多、項目越龐大，採用依賴致使原則的意義就越重大。如今很流行的TDD開發模式就是依賴倒置原則最成功的應用。

傳遞依賴關係有三種方式，以上的例子中使用的方法是接口傳遞，另外還有兩種傳遞方式：構造方法傳遞和setter方法傳遞，相信用過Spring框架的，對依賴的傳遞方式必定不會陌生。
在實際編程中，咱們通常須要作到以下3點：

低層模塊儘可能都要有抽象類或接口，或者二者都有。
變量的聲明類型儘可能是抽象類或接口。
使用繼承時遵循里氏替換原則。

依賴倒置原則的核心就是要咱們面向接口編程，理解了面向接口編程，也就理解了依賴倒置。

接口隔離原則

定義

客戶端不該該依賴它不須要的接口；一個類對另外一個類的依賴應該創建在最小的接口上。

問題由來

類A經過接口I依賴類B，類C經過接口I依賴類D，若是接口I對於類A和類B來講不是最小接口，則類B和類D必須去實現他們不須要的方法。

解決方案

將臃腫的接口I拆分爲獨立的幾個接口，類A和類C分別與他們須要的接口創建依賴關係。也就是採用接口隔離原則。

舉例來講明接口隔離原則：

圖 1 - 未遵循接口隔離原則的設計

這個圖的意思是：類A依賴接口I中的方法一、方法二、方法3，類B是對類A依賴的實現。類C依賴接口I中的方法一、方法四、方法5，類D是對類C依賴的實現。對於類B和類D來講，雖然他們都存在着用不到的方法（也就是圖中紅色字體標記的方法），但因爲實現了接口I，因此也必需要實現這些用不到的方法。對類圖不熟悉的能夠參照程序代碼來理解，代碼以下：

interface I { public void method1(); public void method2(); public void method3(); public void method4(); public void method5(); } class A{ public void depend1(I i){ i.method1(); } public void depend2(I i){ i.method2(); } public void depend3(I i){ i.method3(); } } class B implements I{ public void method1() { System.out.println("類B實現接口I的方法1"); } public void method2() { System.out.println("類B實現接口I的方法2"); } public void method3() { System.out.println("類B實現接口I的方法3"); } //對於類B來講，method4和method5不是必需的，可是因爲接口A中有這兩個方法， //因此在實現過程當中即便這兩個方法的方法體爲空，也要將這兩個沒有做用的方法進行實現。 public void method4() {} public void method5() {} } class C{ public void depend1(I i){ i.method1(); } public void depend2(I i){ i.method4(); } public void depend3(I i){ i.method5(); } } class D implements I{ public void method1() { System.out.println("類D實現接口I的方法1"); } //對於類D來講，method2和method3不是必需的，可是因爲接口A中有這兩個方法， //因此在實現過程當中即便這兩個方法的方法體爲空，也要將這兩個沒有做用的方法進行實現。 public void method2() {} public void method3() {} public void method4() { System.out.println("類D實現接口I的方法4"); } public void method5() { System.out.println("類D實現接口I的方法5"); } } public class Client{ public static void main(String[] args){ A a = new A(); a.depend1(new B()); a.depend2(new B()); a.depend3(new B()); C c = new C(); c.depend1(new D()); c.depend2(new D()); c.depend3(new D()); } }

能夠看到，若是接口過於臃腫，只要接口中出現的方法，無論對依賴於它的類有沒有用處，實現類中都必須去實現這些方法，這顯然不是好的設計。若是將這個設計修改成符合接口隔離原則，就必須對接口I進行拆分。在這裏咱們將原有的接口I拆分爲三個接口，拆分後的設計如圖2所示：

圖 2 - 遵循接口隔離原則的設計）

照例貼出程序的代碼，供不熟悉類圖的朋友參考：

interface I1 { public void method1(); } interface I2 { public void method2(); public void method3(); } interface I3 { public void method4(); public void method5(); } class A{ public void depend1(I1 i){ i.method1(); } public void depend2(I2 i){ i.method2(); } public void depend3(I2 i){ i.method3(); } } class B implements I1, I2{ public void method1() { System.out.println("類B實現接口I1的方法1"); } public void method2() { System.out.println("類B實現接口I2的方法2"); } public void method3() { System.out.println("類B實現接口I2的方法3"); } } class C{ public void depend1(I1 i){ i.method1(); } public void depend2(I3 i){ i.method4(); } public void depend3(I3 i){ i.method5(); } } class D implements I1, I3{ public void method1() { System.out.println("類D實現接口I1的方法1"); } public void method4() { System.out.println("類D實現接口I3的方法4"); } public void method5() { System.out.println("類D實現接口I3的方法5"); } }

接口隔離原則的含義是：創建單一接口，不要創建龐大臃腫的接口，儘可能細化接口，接口中的方法儘可能少。也就是說，咱們要爲各個類創建專用的接口，而不要試圖去創建一個很龐大的接口供全部依賴它的類去調用。本文例子中，將一個龐大的接口變動爲3個專用的接口所採用的就是接口隔離原則。在程序設計中，依賴幾個專用的接口要比依賴一個綜合的接口更靈活。接口是設計時對外部設定的"契約"，經過分散定義多個接口，能夠預防外來變動的擴散，提升系統的靈活性和可維護性。

說到這裏，不少人會覺的接口隔離原則跟以前的單一職責原則很類似，其實否則。其一，單一職責原則原注重的是職責；而接口隔離原則注重對接口依賴的隔離。其二，單一職責原則主要是約束類，其次纔是接口和方法，它針對的是程序中的實現和細節；而接口隔離原則主要約束接口接口，主要針對抽象，針對程序總體框架的構建。

採用接口隔離原則對接口進行約束時，要注意如下幾點：

接口儘可能小，可是要有限度。對接口進行細化能夠提升程序設計靈活性是不掙的事實，可是若是太小，則會形成接口數量過多，使設計複雜化。因此必定要適度。
爲依賴接口的類定製服務，只暴露給調用的類它須要的方法，它不須要的方法則隱藏起來。只有專一地爲一個模塊提供定製服務，才能創建最小的依賴關係。
提升內聚，減小對外交互。使接口用最少的方法去完成最多的事情。

運用接口隔離原則，必定要適度，接口設計的過大或太小都很差。設計接口的時候，只有多花些時間去思考和籌劃，才能準確地實踐這一原則。

迪米特法則

定義

一個對象應該對其餘對象保持最少的瞭解。

問題由來

類與類之間的關係越密切，耦合度越大，當一個類發生改變時，對另外一個類的影響也越大。

解決方案

儘可能下降類與類之間的耦合。

自從咱們接觸編程開始，就知道了軟件編程的總的原則：低耦合，高內聚。不管是面向過程編程仍是面向對象編程，只有使各個模塊之間的耦合儘可能的低，才能提升代碼的複用率。低耦合的優勢不言而喻，可是怎麼樣編程才能作到低耦合呢？那正是迪米特法則要去完成的。

迪米特法則又叫最少知道原則，最先是在1987年由美國Northeastern University的Ian Holland提出。通俗的來說，就是一個類對本身依賴的類知道的越少越好。也就是說，對於被依賴的類來講，不管邏輯多麼複雜，都儘可能地的將邏輯封裝在類的內部，對外除了提供的public方法，不對外泄漏任何信息。迪米特法則還有一個更簡單的定義：只與直接的朋友通訊。首先來解釋一下什麼是直接的朋友：每一個對象都會與其餘對象有耦合關係，只要兩個對象之間有耦合關係，咱們就說這兩個對象之間是朋友關係。耦合的方式不少，依賴、關聯、組合、聚合等。其中，咱們稱出現成員變量、方法參數、方法返回值中的類爲直接的朋友，而出如今局部變量中的類則不是直接的朋友。也就是說，陌生的類最好不要做爲局部變量的形式出如今類的內部。

舉一個例子：有一個集團公司，下屬單位有分公司和直屬部門，如今要求打印出全部下屬單位的員工ID。先來看一下違反迪米特法則的設計。

//總公司員工 class Employee{ private String id; public void setId(String id){ this.id = id; } public String getId(){ return id; } } //分公司員工 class SubEmployee{ private String id; public void setId(String id){ this.id = id; } public String getId(){ return id; } } class SubCompanyManager{ public List getAllEmployee(){ List list = new ArrayList(); for(int i=0; i<100; i++){ SubEmployee emp = new SubEmployee(); //爲分公司人員按順序分配一個ID emp.setId("分公司"+i); list.add(emp); } return list; } } class CompanyManager{ public List getAllEmployee(){ List list = new ArrayList(); for(int i=0; i<30; i++){ Employee emp = new Employee(); //爲總公司人員按順序分配一個ID emp.setId("總公司"+i); list.add(emp); } return list; } public void printAllEmployee(SubCompanyManager sub){ List list1 = sub.getAllEmployee(); for(SubEmployee e:list1){ System.out.println(e.getId()); } List list2 = this.getAllEmployee(); for(Employee e:list2){ System.out.println(e.getId()); } } } public class Client{ public static void main(String[] args){ CompanyManager e = new CompanyManager(); e.printAllEmployee(new SubCompanyManager()); } }

如今這個設計的主要問題出在CompanyManager中，根據迪米特法則，只與直接的朋友發生通訊，而SubEmployee類並非CompanyManager類的直接朋友（以局部變量出現的耦合不屬於直接朋友），從邏輯上講總公司只與他的分公司耦合就好了，與分公司的員工並無任何聯繫，這樣設計顯然是增長了沒必要要的耦合。按照迪米特法則，應該避免類中出現這樣非直接朋友關係的耦合。修改後的代碼以下:

class SubCompanyManager{ public List getAllEmployee(){ List list = new ArrayList(); for(int i=0; i<100; i++){ SubEmployee emp = new SubEmployee(); //爲分公司人員按順序分配一個ID emp.setId("分公司"+i); list.add(emp); } return list; } public void printEmployee(){ List list = this.getAllEmployee(); for(SubEmployee e:list){ System.out.println(e.getId()); } } } class CompanyManager{ public List getAllEmployee(){ List list = new ArrayList(); for(int i=0; i<30; i++){ Employee emp = new Employee(); //爲總公司人員按順序分配一個ID emp.setId("總公司"+i); list.add(emp); } return list; } public void printAllEmployee(SubCompanyManager sub){ sub.printEmployee(); List list2 = this.getAllEmployee(); for(Employee e:list2){ System.out.println(e.getId()); } } }

修改後，爲分公司增長了打印人員ID的方法，總公司直接調用來打印，從而避免了與分公司的員工發生耦合。

迪米特法則的初衷是下降類之間的耦合，因爲每一個類都減小了沒必要要的依賴，所以的確能夠下降耦合關係。可是凡事都有度，雖然能夠避免與非直接的類通訊，可是要通訊，必然會經過一個"中介"來發生聯繫，例如本例中，總公司就是經過分公司這個"中介"來與分公司的員工發生聯繫的。過度的使用迪米特原則，會產生大量這樣的中介和傳遞類，致使系統複雜度變大。因此在採用迪米特法則時要反覆權衡，既作到結構清晰，又要高內聚低耦合。

開閉原則

定義

一個軟件實體如類、模塊和函數應該對擴展開放，對修改關閉。

問題由來

在軟件的生命週期內，由於變化、升級和維護等緣由須要對軟件原有代碼進行修改時，可能會給舊代碼中引入錯誤，也可能會使咱們不得不對整個功能進行重構，而且須要原有代碼通過從新測試。

解決方案

當軟件須要變化時，儘可能經過擴展軟件實體的行爲來實現變化，而不是經過修改已有的代碼來實現變化。

開閉原則是面向對象設計中最基礎的設計原則，它指導咱們如何創建穩定靈活的系統。開閉原則多是設計模式六項原則中定義最模糊的一個了，它只告訴咱們對擴展開放，對修改關閉，但是到底如何才能作到對擴展開放，對修改關閉，並無明確的告訴咱們。之前，若是有人告訴我"你進行設計的時候必定要遵照開閉原則"，我會覺的他什麼都沒說，但貌似又什麼都說了。由於開閉原則真的太虛了。

在仔細思考以及仔細閱讀不少設計模式的文章後，終於對開閉原則有了一點認識。其實，咱們遵循設計模式前面5大原則，以及使用23種設計模式的目的就是遵循開閉原則。也就是說，只要咱們對前面5項原則遵照的好了，設計出的軟件天然是符合開閉原則的，這個開閉原則更像是前面五項原則遵照程度的"平均得分"，前面5項原則遵照的好，平均分天然就高，說明軟件設計開閉原則遵照的好；若是前面5項原則遵照的很差，則說明開閉原則遵照的很差。

其實筆者認爲，開閉原則無非就是想表達這樣一層意思：用抽象構建框架，用實現擴展細節。由於抽象靈活性好，適應性廣，只要抽象的合理，能夠基本保持軟件架構的穩定。而軟件中易變的細節，咱們用從抽象派生的實現類來進行擴展，當軟件須要發生變化時，咱們只須要根據需求從新派生一個實現類來擴展就能夠了。固然前提是咱們的抽象要合理，要對需求的變動有前瞻性和預見性才行。

說到這裏，再回想一下前面說的5項原則，偏偏是告訴咱們用抽象構建框架，用實現擴展細節的注意事項而已：單一職責原則告訴咱們實現類要職責單一；里氏替換原則告訴咱們不要破壞繼承體系；依賴倒置原則告訴咱們要面向接口編程；接口隔離原則告訴咱們在設計接口的時候要精簡單一；迪米特法則告訴咱們要下降耦合。而開閉原則是總綱，他告訴咱們要對擴展開放，對修改關閉。

最後說明一下如何去遵照這六個原則。對這六個原則的遵照並非是和否的問題，而是多和少的問題，也就是說，咱們通常不會說有沒有遵照，而是說遵照程度的多少。任何事都是過猶不及，設計模式的六個設計原則也是同樣，制定這六個原則的目的並非要咱們刻板的遵照他們，而須要根據實際狀況靈活運用。對他們的遵照程度只要在一個合理的範圍內，就算是良好的設計。咱們用一幅圖來講明一下。

圖中的每一條維度各表明一項原則，咱們依據對這項原則的遵照程度在維度上畫一個點，則若是對這項原則遵照的合理的話，這個點應該落在紅色的同心圓內部；若是遵照的差，點將會在小圓內部；若是過分遵照，點將會落在大圓外部。一個良好的設計體如今圖中，應該是六個頂點都在同心圓中的六邊形。

在上圖中，設計一、設計2屬於良好的設計，他們對六項原則的遵照程度都在合理的範圍內；設計三、設計4設計雖然有些不足，但也基本能夠接受；設計5則嚴重不足，對各項原則都沒有很好的遵照；而設計6則遵照過渡了，設計5和設計6都是迫切須要重構的設計。

到這裏，設計模式的六大原則就寫完了。主要參考書籍有《設計模式》《設計模式之禪》《大話設計模式》以及網上一些零散的文章，但主要內容主要仍是我本人對這六個原則的感悟。寫出來的目的一方面是對這六項原則系統地整理一下，一方面也與廣大的網友分享，由於設計模式對編程人員來講，的確很是重要。