一.單一職責原則 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.覆寫或實現父類的方法時輸出結果可以被縮小。
注:在類中調用其他類時務必要使用父類或接口,如果不能使用父類或接口,則說明類的設計已經違背了LSP原則。
三.依賴倒置原則 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方法傳遞依賴對象。
最佳實踐:
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.可見視圖變化
接口設計需要考慮哪些方面
- 接口的命名。
- 請求參數。
- 支持的協議。
- TPS、併發數、響應時長。
- 數據存儲。DB選型、緩存選型。
- 是否需要依賴於第三方。
- 接口是否拆分。
- 接口是否需要冪等。
- 防刷。
- 接口限流、降級。
- 負載均衡器支持。
- 如何部署。
- 是否需要服務治理。
- 是否存在單點。
- 接口是否資源包、預加載還是內置。
- 是否需要本地緩存。
- 是否需要分佈式緩存、緩存穿透怎麼辦。
- 是否需要白名單。
喜歡我的文章的話,就關注我吧!在本頭條號的置頂文章中有【文章分類】包含:
[C++進階篇系列]
[高級網絡編程篇系列]
[Linux系統篇系列]
[C++基礎知識篇]
[協議篇系列]
[數據結構和算法系列]
[設計模式系列]
不要只收藏和轉發哦,寫文章其實很累的。
閱讀更多 cpp軟件架構獅 的文章