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

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

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

類的復雜性降低，實現什么職責都有清晰明確的定義；

可讀性提高，復雜性降低，那當然可讀性提高了；

可維護性提高，可讀性提高，那當然更容易維護了；

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

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

優點

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

提高代碼的重用性；

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

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

提高產品或項目的開放性。

缺點

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

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

增強了耦合性。當父類的常量、變量和方法被修改時，需要考慮子類的修改，而且在缺乏規范的環境下，這種修改可能帶來非常糟糕的結果——大段的代碼需要重構。

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的行為沒有發生變化，那么類型S是類型T的子類型。

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

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

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

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

子類必須完全實現父類的方法

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

子類可以有自己的個性

覆蓋或實現父類的方法時輸入參數可以被放大(重載而非覆蓋)

覆寫或實現父類的方法時輸出結果可以被縮小

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

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

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.

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

依賴倒置原則在Java中的體現：

模塊間的依賴通過抽象發生，實現類之間不發生直接的依賴關系，其依賴關系是通過接口或抽象類產生的；

接口或抽象類不依賴于實現類；

實現類依賴接口或抽象類。

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

構造函數傳遞依賴對象（構造函數注入），在類中通過構造函數聲明依賴對象

Setter方法傳遞依賴對象（Setter依賴注入），在抽象中設置Setter方法聲明依賴關系

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

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

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

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

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

任何類都不應該從具體類派生

盡量不要覆寫基類的方法

結合里氏替換原則使用

父類出現的地方子類就能出現，再DIP，我們可以得出這樣一個通俗的規則： 接口負責定義public屬性和方法，并且聲明與其他對象的依賴關系，抽象類負責公共構造部分的實現，實現類準確的實現業務邏輯，同時在適當的時候對父類進行細化。

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

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

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

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

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

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

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

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

單一職責要求的是類和接口職責單一，注重的是職責，這是業務邏輯上的劃分；

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

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

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

接口要盡量小

要有限度

不能違背單一職責原則（業務上的劃分）

接口要高內聚

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

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

舉例說明：一個用于查詢用戶的接口，應該提供具體的根據用戶ID查詢或者根據用戶名查詢等于業務相關的特定接口，而不是提供一個帶有Map（或者說類似Mybatis Example）參數的查詢接口

接口設計是有限度的

接口的設計粒度越小，系統越靈活；

但是，靈活的同時也帶來了結構的復雜化，開發難度增加，可維護性降低，這不是一個項目或產品所期望看到的；

所以接口設計一定要注意適度，這個“度”如何來判斷呢？根據經驗和常識判斷，沒有一個固化或可測量的標準。

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

一個接口只服務于一個子模塊或業務邏輯；

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

已經被污染了的接口，盡量去修改，若變更的風險較大，則采用適配器模式進行轉化處理；

了解環境，拒絕盲從。每個項目或產品都有特定的環境因素，環境不同，接口拆分的標準就不同。深入了解業務邏輯，結合實際情況進行接口設計。

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

一個對象應該對其他對象有最少的了解

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

只和朋友交流

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

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

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

朋友間也是有距離的

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

是自己的就是自己的

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

謹慎使用Serializable

迪米特法則的核心觀念就是類間解耦，弱耦合，只有弱耦合了以后，類的復用率才可以提高。其要求的結果就是產生了大量的中轉或跳轉類，導致系統的復雜性提高，同時也為維護帶來了難度。在采用迪米特法則時需要反復權衡，既做到讓結構清晰，又做到高內聚低耦合。

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

開閉原則是Java世界里最基礎的設計原則，它指導我們如何建立一個穩定的、靈活的系統

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

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

開閉原則是最基礎的一個原則，前面節介紹的五個原則都是開閉原則的具體形態，也就是說前五個原則就是指導設計的工具和方法，而開閉原則才是其精神領袖。換一個角度來理解，依照Java語言的稱謂，開閉原則是抽象類，其他五大原則是具體的實現類，開閉原則在面向對象設計領域中的地位就類似于牛頓第一定律在力學、勾股定律在幾何學、質能方程在狹義相對論中的地位，其地位無人能及。

抽象約束

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

參數類型、引用對象盡量使用接口或者抽象類，而不是實現類；

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

元數據（metadata）控制模塊行為

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

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

封裝變化

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

將不同的變化封裝到不同的接口或抽象類中，不應該有兩個不同的變化出現在同一個接口或抽象類中。

封裝變化，也就是受保護的變化（protected variations），找出預計有變化或不穩定的點，我們為這些變化點創建穩定的接口，準確地講是封裝可能發生的變化，一旦預測到或“第六感”發覺有變化，就可以進行封裝，23個設計模式都是從各個不同的角度對變化進行封裝的

開閉原則也只是一個原則

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

項目規章非常重要

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

預知變化

在實踐中過程中，架構師或項目經理一旦發現有發生變化的可能，或者變化曾經發生過，則需要考慮現有的架構是否可以輕松地實現這一變化。架構師設計一套系統不僅要符合現有的需求，還要適應可能發生的變化，這才是一個優良的架構。

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

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

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

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

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

設計做得再漂亮，代碼寫得再完美，項目做得再符合標準，一旦項目虧本，產品投入大于產出，那整體就是扯淡！

參考文獻：《設計模式之禪》