摘要：依賴倒置原則是個設(shè)計原則中最難以實現(xiàn)的原則，它是實現(xiàn)開閉原則的重要途徑，依賴倒置原則沒有實現(xiàn)，就別想實現(xiàn)對擴展開放，對修改關(guān)閉。

There should never be more than one reason for a class to change.
應(yīng)該有且僅有一個原因引起類的變更

換言之，也就是一個接口或類只有一個職責(zé)

類的復(fù)雜性降低，實現(xiàn)什么職責(zé)都有清晰明確的定義；

可讀性提高，復(fù)雜性降低，那當(dāng)然可讀性提高了；

可維護性提高，可讀性提高，那當(dāng)然更容易維護了；

變更引起的風(fēng)險降低，變更時必不可少的，如果接口的單一職責(zé)做得好，一個接口修改只對相應(yīng)的實現(xiàn)類有影響，對其他的接口無影響，這對系統(tǒng)的擴展性、維護性都有非常大的幫助。

職責(zé)的劃分很難，要想完全符合單一職責(zé)的設(shè)計更難，原則是接口一定要做到單一職責(zé)，類的設(shè)計盡量做到只有一個原因引起變化

優(yōu)點

代碼共享，減少創(chuàng)建類的工作量，每個子類都擁有父類的方法和屬性；

提高代碼的重用性；

子類可以形似父類，但又異于父類；

提高代碼的可擴展性，實現(xiàn)父類的方法就可以“為所欲為”了；

提高產(chǎn)品或項目的開放性。

缺點

繼承是侵入性的。只要繼承，就必須擁有父類的所有屬性和方法；

降低代碼的靈活性。子類必須擁有父類的屬性和方法，讓子類自由的世界中多了些約束；

增強了耦合性。當(dāng)父類的常量、變量和方法被修改時，需要考慮子類的修改，而且在缺乏規(guī)范的環(huán)境下，這種修改可能帶來非常糟糕的結(jié)果——大段的代碼需要重構(gòu)。

If for each object o1 of type S there is an object o2 oftype T such that for all programs P defined in terms of T,the behavior of P is unchanged when o1 issubstituted for o2 then S is a subtype of T.
如果對每一個類型為S的對象o1，都有類型為T的對象o2，使得以T定義的所有程序P在所有的對象o1都代換成o2時，程序P的行為沒有發(fā)生變化，那么類型S是類型T的子類型。

以上是LSP"最正宗"的定義，但是可能不太容易理解，它還有另外一種相對清晰明確的定義：

Functions that use pointers or references to base classes must be able to useobjects of derived classes without knowing it.
所有引用基類的地方必須能透明地使用其子類的對象。

通俗點講，只要父類能出現(xiàn)的地方子類就可以出現(xiàn)，而且替換為子類也不會產(chǎn)生任何錯誤或異常，使用者可能根本就不需要知道是父類還是子類。但是，反過來就不行了，有子類出現(xiàn)的地方，父類未必就能適應(yīng)。(LSP可以正著用但不能反著用)

里氏替換原則為良好的繼承定義了一個規(guī)范，一句簡單的定義包含了4層含義：

子類必須完全實現(xiàn)父類的方法

如果子類不能完整地實現(xiàn)父類的方法，或者父類的某些方法在子類中已經(jīng)發(fā)生“畸變”，則建議斷開父子繼承關(guān)系，采用依賴、聚集、組合等關(guān)系代替繼承。

子類可以有自己的個性

覆蓋或?qū)崿F(xiàn)父類的方法時輸入?yún)?shù)可以被放大(重載而非覆蓋)

覆寫或?qū)崿F(xiàn)父類的方法時輸出結(jié)果可以被縮小

父類的一個方法的返回值是一個類型T，子類的相同方法（重載或覆寫）的返回值為S，那么里氏替換原則就要求S必須小于等于T，也就是說，要么S和T是同一個類型，要么S是T的子類。

在項目中，采用里氏替換原則時，盡量避免子類的“個性”，一旦子類有“個性”，這個子類和父類之間的關(guān)系就很難調(diào)和了，把子類當(dāng)做父類使用，子類的“個性”被抹殺——委屈了點；把子類多帶帶作為一個業(yè)務(wù)來使用，則會讓代碼間的耦合關(guān)系變得撲朔迷離——缺乏類替換的標(biāo)準(zhǔn)。

High level modules should not depend upon low level modules.Both should depend uponabstractions.Abstractions should not depend upon details.Details should depend upon abstractions.

高層模塊不應(yīng)該依賴低層模塊，兩者都應(yīng)該依賴其抽象；
抽象不應(yīng)該依賴細(xì)節(jié)；
細(xì)節(jié)應(yīng)該依賴抽象。

依賴倒置原則在Java中的體現(xiàn)：

模塊間的依賴通過抽象發(fā)生，實現(xiàn)類之間不發(fā)生直接的依賴關(guān)系，其依賴關(guān)系是通過接口或抽象類產(chǎn)生的；

接口或抽象類不依賴于實現(xiàn)類；

實現(xiàn)類依賴接口或抽象類。

更加精簡的定義就是“面向接口編程”。

構(gòu)造函數(shù)傳遞依賴對象（構(gòu)造函數(shù)注入），在類中通過構(gòu)造函數(shù)聲明依賴對象

Setter方法傳遞依賴對象（Setter依賴注入），在抽象中設(shè)置Setter方法聲明依賴關(guān)系

在接口的方法中聲明依賴對象（接口注入）

依賴倒置原則的本質(zhì)就是通過抽象（接口或抽象類）使各個類或模塊的實現(xiàn)彼此獨立，不互相影響，實現(xiàn)模塊間的松耦合，我們怎么在項目中使用這個規(guī)則呢？只要遵循以下的幾個規(guī)則就可以：

每個類盡量都有接口或抽象類，或者抽象類和接口兩者都具備

這是依賴倒置的基本要求，接口和抽象類都是屬于抽象的，有了抽象才可能依賴倒置

變量的表面類型盡量是接口或者是抽象類

任何類都不應(yīng)該從具體類派生

盡量不要覆寫基類的方法

結(jié)合里氏替換原則使用

父類出現(xiàn)的地方子類就能出現(xiàn)，再DIP，我們可以得出這樣一個通俗的規(guī)則： 接口負(fù)責(zé)定義public屬性和方法，并且聲明與其他對象的依賴關(guān)系，抽象類負(fù)責(zé)公共構(gòu)造部分的實現(xiàn)，實現(xiàn)類準(zhǔn)確的實現(xiàn)業(yè)務(wù)邏輯，同時在適當(dāng)?shù)臅r候?qū)Ω割愡M行細(xì)化。

依賴倒置原則是6個設(shè)計原則中最難以實現(xiàn)的原則，它是實現(xiàn)開閉原則的重要途徑，依賴倒置原則沒有實現(xiàn)，就別想實現(xiàn)對擴展開放，對修改關(guān)閉。在項目中，大家只要記住是“面向接口編程”就基本上抓住了依賴倒置原則的核心。

接口隔離原則有以下兩種定義：

Clients should not be forced to depend upon interfaces that they don"t use.
客戶端不應(yīng)該依賴它不需要的接口。

解釋：客戶端需要什么接口就提供什么接口，把不需要的接口剔除掉，那就需要對接口進行細(xì)化，保證其純潔性；

The dependency of one class to another one should depend on the smallest possible interface.
類間的依賴關(guān)系應(yīng)該建立在最小的接口上。

解釋：要求是最小的接口，也是要求接口細(xì)化，接口純潔，與第一個定義如出一轍，只是一個事物的兩種不同描述。

概括：建立單一接口，不要建立臃腫龐大的接口。再通俗一點講：接口盡量細(xì)化，同時接口中的方法盡量少。

接口隔離原則與單一職責(zé)的審視角度是不相同的

單一職責(zé)要求的是類和接口職責(zé)單一，注重的是職責(zé)，這是業(yè)務(wù)邏輯上的劃分；

接口隔離原則要求接口的方法盡量少。

例如一個接口的職責(zé)可能包含10個方法，這10個方法都放在一個接口中，并且提供給多個模塊訪問，各個模塊按照規(guī)定的權(quán)限來訪問，在系統(tǒng)外通過文檔約束“不使用的方法不要訪問”，按照單一職責(zé)原則是允許的，按照接口隔離原則是不允許的，因為它要求“盡量使用多個專門的接口”。專門的接口指什么？就是指提供給每個模塊的都應(yīng)該是單一接口，提供給幾個模塊就應(yīng)該有幾個接口，而不是建立一個龐大的臃腫的接口，容納所有的客戶端訪問。

// TODO 還是感覺差不太多...

接口要盡量小

要有限度

不能違背單一職責(zé)原則（業(yè)務(wù)上的劃分）

接口要高內(nèi)聚

高內(nèi)聚具體到接口隔離原則就是，要求在接口中盡量少公布public方法，接口是對外的承諾，承諾越少對系統(tǒng)的開發(fā)越有利，變更的風(fēng)險也就越少，同時也有利于降低成本。

定制服務(wù)（只提供訪問者需要的方法）

舉例說明：一個用于查詢用戶的接口，應(yīng)該提供具體的根據(jù)用戶ID查詢或者根據(jù)用戶名查詢等于業(yè)務(wù)相關(guān)的特定接口，而不是提供一個帶有Map（或者說類似Mybatis Example）參數(shù)的查詢接口

接口設(shè)計是有限度的

接口的設(shè)計粒度越小，系統(tǒng)越靈活；

但是，靈活的同時也帶來了結(jié)構(gòu)的復(fù)雜化，開發(fā)難度增加，可維護性降低，這不是一個項目或產(chǎn)品所期望看到的；

所以接口設(shè)計一定要注意適度，這個“度”如何來判斷呢？根據(jù)經(jīng)驗和常識判斷，沒有一個固化或可測量的標(biāo)準(zhǔn)。

接口隔離原則是對接口的定義，同時也是對類的定義，接口和類盡量使用原子接口或原子類來組裝。但是，這個原子該怎么劃分是設(shè)計模式中的一大難題，在實踐中可以根據(jù)以下幾個規(guī)則來衡量：

一個接口只服務(wù)于一個子模塊或業(yè)務(wù)邏輯；

通過業(yè)務(wù)邏輯壓縮接口中的public方法，接口時常去回顧，盡量讓接口達(dá)到“滿身筋骨肉”，而不是“肥嘟嘟”的一大堆方法；

已經(jīng)被污染了的接口，盡量去修改，若變更的風(fēng)險較大，則采用適配器模式進行轉(zhuǎn)化處理；

了解環(huán)境，拒絕盲從。每個項目或產(chǎn)品都有特定的環(huán)境因素，環(huán)境不同，接口拆分的標(biāo)準(zhǔn)就不同。深入了解業(yè)務(wù)邏輯，結(jié)合實際情況進行接口設(shè)計。

也稱為最少知識原則（Least KnowledgePrinciple，LKP）

一個對象應(yīng)該對其他對象有最少的了解

通俗地講，一個類應(yīng)該對自己需要耦合或調(diào)用的類知道得最少，你（被耦合或調(diào)用的類）的內(nèi)部是如何復(fù)雜都和我沒關(guān)系，那是你的事情，我就知道你提供的這么多public方法，我就調(diào)用這么多，其他的我一概不關(guān)心。

只和朋友交流

迪米特法則還有一個英文解釋是：

Only talk to your immediate friends.
只與直接的朋友通信。

一個類只和朋友交流，不與陌生類交流，不要出現(xiàn)getA().getB().getC().getD()這種情況（在一種極端的情況下允許出現(xiàn)這種訪問，即每一個點號后面的返回類型都相同），類與類之間的關(guān)系是建立在類間的，而不是方法間，因此一個方法盡量不引入一個類中不存在的對象，當(dāng)然，JDK API提供的類除外。

朋友間也是有距離的

迪米特法則要求類“羞澀”一點，盡量不要對外公布太多的public方法和非靜態(tài)的public變量，盡量內(nèi)斂，多使用private、package-private、protected等訪問權(quán)限。

是自己的就是自己的

在實際應(yīng)用中經(jīng)常會出現(xiàn)這樣一個方法：放在本類中也可以，放在其他類中也沒有錯，那怎么去衡量呢？你可以堅持這樣一個原則：如果一個方法放在本類中，既不增加類間關(guān)系，也對本類不產(chǎn)生負(fù)面影響，那就放置在本類中。

謹(jǐn)慎使用Serializable

迪米特法則的核心觀念就是類間解耦，弱耦合，只有弱耦合了以后，類的復(fù)用率才可以提高。其要求的結(jié)果就是產(chǎn)生了大量的中轉(zhuǎn)或跳轉(zhuǎn)類，導(dǎo)致系統(tǒng)的復(fù)雜性提高，同時也為維護帶來了難度。在采用迪米特法則時需要反復(fù)權(quán)衡，既做到讓結(jié)構(gòu)清晰，又做到高內(nèi)聚低耦合。

迪米特法則要求類間解耦，但解耦是有限度的，除非是計算機的最小單元——二進制的0和1。那才是完全解耦，在實際的項目中，需要適度地考慮這個原則，別為了套用原則而做項目。原則只是供參考，如果違背了這個原則，項目也未必會失敗，這就需要大家在采用原則時反復(fù)度量，不遵循是不對的，嚴(yán)格執(zhí)行就是“過猶不及”。

開閉原則是Java世界里最基礎(chǔ)的設(shè)計原則，它指導(dǎo)我們?nèi)绾谓⒁粋€穩(wěn)定的、靈活的系統(tǒng)

Software entities like classes,modules and functions should be open for extension but closed formodifications.
一個軟件實體如類、模塊和函數(shù)應(yīng)該對擴展開放，對修改關(guān)閉。

換句話說，一個軟件實體應(yīng)該通過擴展來實現(xiàn)變化，而不是通過修改已有的代碼來實現(xiàn)變化。

開閉原則是最基礎(chǔ)的一個原則，前面節(jié)介紹的五個原則都是開閉原則的具體形態(tài)，也就是說前五個原則就是指導(dǎo)設(shè)計的工具和方法，而開閉原則才是其精神領(lǐng)袖。換一個角度來理解，依照J(rèn)ava語言的稱謂，開閉原則是抽象類，其他五大原則是具體的實現(xiàn)類，開閉原則在面向?qū)ο笤O(shè)計領(lǐng)域中的地位就類似于牛頓第一定律在力學(xué)、勾股定律在幾何學(xué)、質(zhì)能方程在狹義相對論中的地位，其地位無人能及。

抽象約束

通過接口或抽象類約束擴展，對擴展進行邊界限定，不允許出現(xiàn)在接口或抽象類中不存在的public方法；

參數(shù)類型、引用對象盡量使用接口或者抽象類，而不是實現(xiàn)類；

抽象層盡量保持穩(wěn)定，一旦確定即不允許修改。

元數(shù)據(jù)（metadata）控制模塊行為

何謂元數(shù)據(jù)？就是用來描述環(huán)境和數(shù)據(jù)的數(shù)據(jù)，通俗地說就是配置參數(shù)，參數(shù)可以從文件中獲得，也可以從數(shù)據(jù)庫中獲得。

制定項目章程（團隊約定）

封裝變化

將相同的變化封裝到一個接口或抽象類中；

將不同的變化封裝到不同的接口或抽象類中，不應(yīng)該有兩個不同的變化出現(xiàn)在同一個接口或抽象類中。

封裝變化，也就是受保護的變化（protected variations），找出預(yù)計有變化或不穩(wěn)定的點，我們?yōu)檫@些變化點創(chuàng)建穩(wěn)定的接口，準(zhǔn)確地講是封裝可能發(fā)生的變化，一旦預(yù)測到或“第六感”發(fā)覺有變化，就可以進行封裝，23個設(shè)計模式都是從各個不同的角度對變化進行封裝的

開閉原則也只是一個原則

開閉原則只是精神口號，實現(xiàn)擁抱變化的方法非常多，并不局限于這6大設(shè)計原則，但是遵循這6大設(shè)計原則基本上可以應(yīng)對大多數(shù)變化。因此，我們在項目中應(yīng)盡量采用這6大原則，適當(dāng)時候可以進行擴充，例如通過類文件替換的方式完全可以解決系統(tǒng)中的一些缺陷。大家在開發(fā)中比較常用的修復(fù)缺陷的方法就是類替換，比如一個軟件產(chǎn)品已經(jīng)在運行中，發(fā)現(xiàn)了一個缺陷，需要修正怎么辦？如果有自動更新功能，則可以下載一個.class文件直接覆蓋原有的class，重新啟動應(yīng)用（也不一定非要重新啟動）就可以解決問題，也就是通過類文件的替換方式修正了一個缺陷，當(dāng)然這種方式也可以應(yīng)用到項目中，正在運行中的項目發(fā)現(xiàn)需要增加一個新功能，通過修改原有實現(xiàn)類的方式就可以解決這個問題，前提條件是：類必須做到高內(nèi)聚、低耦合，否則類文件的替換會引起不可預(yù)料的故障。

項目規(guī)章非常重要

如果你是一位項目經(jīng)理或架構(gòu)師，應(yīng)盡量讓自己的項目成員穩(wěn)定，穩(wěn)定后才能建立高效的團隊文化，章程是一個團隊所有成員共同的知識結(jié)晶，也是所有成員必須遵守的約定。優(yōu)秀的章程能帶給項目帶來非常多的好處，如提高開發(fā)效率、降低缺陷率、提高團隊士氣、提高技術(shù)成員水平，等等。

預(yù)知變化

在實踐中過程中，架構(gòu)師或項目經(jīng)理一旦發(fā)現(xiàn)有發(fā)生變化的可能，或者變化曾經(jīng)發(fā)生過，則需要考慮現(xiàn)有的架構(gòu)是否可以輕松地實現(xiàn)這一變化。架構(gòu)師設(shè)計一套系統(tǒng)不僅要符合現(xiàn)有的需求，還要適應(yīng)可能發(fā)生的變化，這才是一個優(yōu)良的架構(gòu)。

開閉原則是一個終極目標(biāo)，任何人包括大師級人物都無法百分之百做到，但朝這個方向努力，可以非常顯著地改善一個系統(tǒng)的架構(gòu)，真正做到“擁抱變化”。

首先，無論是6大設(shè)計原則還是23種設(shè)計模式，根本目標(biāo)其實就是一個"擁抱變化"，包括需求的變化、運行環(huán)境的變化、性能要求的提升等等，實現(xiàn)一個需求并不難，但是當(dāng)變化來臨時，能否泰然處之，那就是個技術(shù)活了。

其次，"擁抱變化"落實到代碼層面是什么？——你的代碼是可維護的、可擴展的，還是說"牽一發(fā)動全身"，一點小的改動很多東西都要跟著變動。

再次，要做到"擁抱變化"，讓你的代碼很容易維護和擴展，核心理念就是"高內(nèi)聚、低耦合"，以及"面向接口編程（面向抽象編程）”

最后，設(shè)計原則、設(shè)計模式是前輩總結(jié)的"經(jīng)驗"，但不是"條款"，盡可能遵循這些規(guī)范會讓你的設(shè)計無限接近完美，但世界上本就沒有十全十美的東西，凡事都要有個度，不要認(rèn)死理，不要為了"套模式"而應(yīng)用設(shè)計模式，要具體問題具體分析，根據(jù)實際情況進行權(quán)衡。

設(shè)計做得再漂亮，代碼寫得再完美，項目做得再符合標(biāo)準(zhǔn)，一旦項目虧本，產(chǎn)品投入大于產(chǎn)出，那整體就是扯淡！

參考文獻(xiàn)：《設(shè)計模式之禪》