1. 程式人生 > >程序接口設計的六大原則

程序接口設計的六大原則

don gin 劃分 一定的 ive 復雜 不能 drive smallest

一.單一職責原則 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方法傳遞依賴對象。
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.可見視圖變化

程序接口設計的六大原則