程序接口設計的六大原則

程序接口設計的六大原則

一.單一職責原則 Single Responsibility Principle, 簡稱SRP。
定義：There should never be more than one reason for a class to change.  應該有且僅有一個緣由引發類的變動。
職責的劃分？單一的定義和級別？
應該根據實際業務狀況而定。關注變化點。
實際使用時，類很難作到職責單一，可是接口的職責應該儘可能單一。

 

二.里氏替換原則 Liskov Substitution Principle, 簡稱LSP。
定義：Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.
(全部引用基類的地方必須能透明地使用其子類的對象)  子類能夠替換父類==原來要求是一個父類的對象 我如今給一個子類的對象 也是能夠的。
里氏替換原則爲良好的繼承定義了一個規範：
1.子類必須徹底實現父類的方法
2.子類能夠有本身的個性（屬性和方法）。
3.覆蓋或實現父類的方法時輸入參數能夠被放大。
4.覆寫或實現父類的方法時輸出結果能夠被縮小。
注：在類中調用其餘類時務必要使用父類或接口，若是不能使用父類或接口，則說明類的設計已經違背了ＬＳＰ原則。

三.依賴倒置原則 Dependence Inversion Principle, 簡稱DIP
定義：High level modules should not depend upon low level modules.Both should depend upon abstractions.Abstractions should not depend upon details.Details should depend upon abstractions.
翻譯過來，包含三層含義：
1.高層模塊不該該依賴低層模塊，二者都應該依賴其抽象。
2.抽象不該該依賴細節。
3.細節應該依賴抽象。

精簡的定義： 面向接口編程。
Test-Driven Development 測試驅動開發是依賴倒置原則的最好體現。
測試驅動開發要求先寫測試類，測試經過才寫實現類，這就要求你要先想接口定義。

依賴的三種寫法：
1.構造函數傳遞依賴對象。
2.Setter方法傳遞依賴對象。
3.接口聲明依賴對象。

最佳實踐：
1.每一個類儘可能都有接口或抽象類，或者抽象類和接口二者都具有。
2.變量的表面類型儘可能是接口或抽象類。
3.任何類都不該該從具體類派生。
4.儘可能不要覆寫基類的方法。
5.結合里氏替換原則使用。

四.接口隔離原則：接口–這裏指用interface關鍵字定義的接口。
定義：
1.Clients should not be forced to depend upon interfaces that they don’t use.(客戶端不該該依賴它不須要的接口)
2.The dependency of one class to anther one should depend on the smallest possible interface.(類間的依賴關係應該創建在最小的接口上)

歸納：創建單一接口，不要創建臃腫龐大的接口。
通俗來說：接口儘可能細化，同時接口中的方法儘可能少。

如何細化？細化到什麼程序？
沒有統一的標準，應根據業務合理細分，適合業務纔是重點。

保證接口的純結性：
1.接口要儘可能小。
2.接口要高內聚。
3.定製服務。
4.接口的設計是有限度的。

最佳實踐：
1.一個接口只服務於一個子模塊或業務邏輯。
2.經過業務邏輯壓縮接口中的public方法，接口時常去回顧，儘可能讓接口達到「滿身筋骨肉」，而不是「肥嘟嘟」的一大堆方法。
3.已經被污染了的接口，儘可能去修改，若變動的風險較大，則採用適配器模式進行轉化處理。
4.瞭解環境，拒絕盲從。每一個項目或產品都有特定的環境因素，不要盲從大師的設計，要根據業務邏輯進行最好的接口設計。

五.迪米特法則 Law of Demeter, LOD。又稱 最少知識原則（Least Knowledge Principle , LKP）
通俗來說：一個類應該對本身須要耦合或調用的類知道得最少，你（被耦合或調用的類）的內部是如何複雜都和我沒有關係，那是你的事情，我就調用你提供的public方法，其餘一律不關心。

低耦合要求：
1.只和朋友交流
朋友類：出如今成員變量、方法的輸入輸出參數中的類。方法體內部的類不屬於朋友類。
2.朋友間也是有距離的
迪米特法則要求類「羞澀」一點，儘可能不要對外公佈太多的public方法和非靜態的public變量，儘可能內斂，多使用private、package-private、protected等訪問權限。
3.是本身的就是本身的
若是一個方法放在本類中，既不增長類間關係，也對本類不產生負面影響，就放置在本類中。
4.謹慎使用Serializable

 

六.開閉原則
Software entities like classes, modules and functions should be open for extension but closed for modifications.（一個軟件實體如類、模塊和函數應該對擴展開放，對修改關閉）
軟件實體包括如下幾個部分：
1.項目和軟件產品中按照必定的邏輯規則劃分的模塊。
2.抽象和類。
3.方法。

變化的三種類型：
1.邏輯變化
2.子模塊變化
3.可見視圖變化

 

 

接口設計須要考慮哪些方面

 

1. 接口的命名。

2. 請求參數。

3. 支持的協議。

4. TPS、併發數、響應時長。

5. 數據存儲。DB選型、緩存選型。

6. 是否須要依賴於第三方。

7. 接口是否拆分。

8. 接口是否須要冪等。

9. 防刷。

10. 接口限流、降級。

11. 負載均衡器支持。

12. 如何部署。

13. 是否須要服務治理。

14. 是否存在單點。

15. 接口是否資源包、預加載仍是內置。

16. 是否須要本地緩存。

17. 是否須要分佈式緩存、緩存穿透怎麼辦。

18. 是否須要白名單。