《設計模式之禪》之六大設計原則中篇

本文主要講依賴倒置原則和接口隔離原則。

1、依賴倒置原則

1.定義

• 高層模塊不該該依賴低層模塊，二者都應該依賴其抽象;
• 抽象不該該依賴細節;
• 細節應該依賴於抽象;

高層模塊和低層模塊容易理解，每個邏輯的實現都是由原子邏輯組成的，不可分割的原子邏輯就是低層模塊，原子邏輯的再組裝就是高層模塊。

那什麼是抽象?什麼又是細節呢?
在Java語言中，抽象就是指接口或抽象類，二者都不能直接被實例化；細節就是實現類，實現接口或者繼承抽象類而產生的類就是細節，其特色是能夠直接被實例化，也就是能夠加上一個關鍵字new產生一個對象。

在Java語言中的表現就是:

• 模塊間的依賴經過抽象發生，實現類之間不發生直接的依賴關係，其依賴關係是經過接口或抽象產生的;
• 接口或抽象類不依賴於實現類;
• 實現類依賴接口或抽象類;

採用依賴倒置原則能夠減小類間的耦合性，提升系統的穩定性，下降並行開發引發的風險，提升代碼的可讀性和可維護性。

注意:設計是否具有穩定性，只要適當地」鬆鬆土」，觀察」設計的藍圖」是否還能夠茁壯地成長就能夠得出結論，穩定性較高的設計，在周圍環境頻繁變化的時候，依然能夠作到」我自巋然不動」。

2.依賴的三種寫法

(1)構造函數傳遞依賴對象

在類中經過構造函數聲明依賴對象，按照依賴注入的說法，這種方式叫作構造函數注入。

(2)Setter方法傳遞依賴對象

在抽象中設置etter方法聲明依賴關係，依照依賴注入的說法，這是Setter依賴注入。

(3)接口聲明依賴對象

在接口的方法中聲明依賴對象。

3.最佳實踐

依賴倒置原則的本質就是經過抽象(接口或抽象類)使各個類或模塊的實現彼此獨立，不互相影響，實現模塊間的鬆耦合，咱們怎麼在項目中使用這個規則呢?
只要遵循以下幾個規則便可:

• 每一個類儘可能都有接口或抽象類或者抽象類和接口二者都具有(這是依賴倒置的基本要求，接口和抽象類都是屬於抽象的，有了抽象纔可能依賴倒置);
• 變量的表面類型儘可能是接口或是抽象類;
• 任何類都不該該從具體類派生;
• 儘可能不要覆寫基類的方法(若是基類是一個抽象類，並且這個方法已經實現了，子類儘可能不要覆寫。類間依賴的是抽象，覆寫了抽象方法，對依賴的穩定性會產生必定的影響);
• 結合里氏替換原則使用;

2、接口隔離原則

1.定義

先明確主角-接口，接口分爲兩種:

• 實例接口，在Java中聲明一個類，而後用new關鍵字產生一個實例，它是對一個類型的事物的描述，這是一種接口。好比你定義Person這個類，而後使用Person zhangSan = new Person()產生了一個實例，這個實例要聽從的標準就是Person這個類，Person類就是zhangSan的接口。Java中的類也是一種接口;
• 類接口，Java中常用的interface關鍵字定義的接口;

那什麼是隔離?
兩種定義以下:

• 客戶端不該該依賴它不須要的接口;
• 類間的依賴關係應該創建在最小的接口上;

先說第一種定義:」客戶端不該該依賴它不須要的接口」，那依賴什麼?依賴它須要的接口，把不須要的接口剔除掉，那就須要對接口進行細化，保證其純潔性;
再看第二種定義:」類間的依賴關係應該創建在最小的接口上」，它要求是最小的接口，也是要求接口細化，接口純潔，與第一個定義一模一樣，只是一個事物的兩種不一樣描述。

概括爲一句話:創建單一的接口，不要創建臃腫龐大的接口(通俗的講:接口儘可能細化，同時接口中的方法儘可能少)。

有人可能會疑惑，這與單一職責原則不是相同嗎?
接口隔離原則和單一職責原則的審視角度是不相同的，單一職責要求的是類和接口職責單一，注重的是職責，這是業務邏輯上的劃分，二接口隔離原則要求接口的方法儘可能少。

例如一個接口的職責可能包含10個方法，這10個方法都放在一個接口中，而且提供多個模塊訪問，在系統外經過文檔約束」不使用的方法不要訪問」，按照單一職責原則是容許的，由於它要求」儘可能使用多個專門的接口」。專門的接口指什麼?就是指提供給每一個模塊的都應該是單一接口，提供給幾個模塊就應該有幾個接口，而不是創建一個龐大的臃腫的接口，容納全部的客戶端訪問。

2.保證接口的純潔性

接口隔離原則是對接口進行規範約束，其包含如下4層含義:

• 接口要儘可能小;
• 接口要高內聚(高內聚就是提升接口、類、模塊的處理能力，減小對外交互);
• 定製服務(定製服務就是單獨爲一個個體提供優良的服務);
• 接口設計是有限度的(接口的設計粒度越小，系統越靈活，這是不爭的事實);

3.最佳實踐

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

• 一個接口只服務於一個子模塊或業務邏輯;
• 經過業務邏輯壓縮接口中的public方法，接口時常去回顧，儘可能讓接口達到」滿身筋骨肉」，而不是」肥嘟嘟」的一大堆方法;
• 已經被污染了的接口，儘可能去修改，若變動風險較大，則採用適配器模式進行轉化處理;
• 瞭解環境，拒絕盲從。每一個項目或產品都有特定的環境因素，別看到大師是這樣作的你就照抄。千萬別，環境不一樣，接口拆分的標準就不一樣。深刻了解業務邏輯，最好的設計就出自你的手中;

那麼怎麼才能正確地使用接口隔離原則呢?
答案是根據經驗和常識決定接口的粒度大小，接口粒度過小，致使接口數據劇增，開發人員嗆死在接口的海洋裏；接口粒度太大，靈活性下降，沒法提供定製服務給總體項目帶來沒法預料的風險。

怎麼準確地實踐接口隔離原則?實踐、經驗和領域。