從全球視野出發 DLF對流雲構建全球去中心化公的‘朝陽專案
一、六大設計原則
1、單一職責原則
【Single Responsibility Principle
】
保證類的職責要單一。
應該有且僅有一個原因引起類的變更。
好處
:
- 類的複雜性降低
- 可讀性提高
- 可維護性提高
- 比那更引起的風險降低
2、里氏替換原則
【Liskov Substitution Principle
】
要求不要破壞繼承體系。
定義
:所有引用基類的地方必須能透明地使用其子類的物件。
只要父類能出現的地方我子類就可以出現,而且呼叫子類還不產生任何的錯誤或異常,呼叫者可能根本就不需要知道是父類還是子類。但是反過來就不成了,有子類出現的地方,父類未必就能適應。
里氏替換法則包含了四層意思
-
子類必須完全的實現父類的方法。
在類中呼叫其他類是務必要使用父類或介面,如果不能使用 父類或介面,則說明類的設計已經違背了
LSP
原則。 -
子類可以有自己的個性。
-
覆蓋或實現父類的方法時輸入引數可以被放大。
子類中方法的前置條件必須與超類中被覆蓋的方法的前置條件相同或 者更寬鬆。
-
覆蓋或實現父類的方法是輸出結果可以被縮小。
3、依賴倒置原則
【Dependence Inversion Principle
】
面向介面去程式設計。
4、介面隔離原則
【Interface Segregation Principle
】
設計介面的時候,要做到精簡單一。
-
介面儘量要小。
-
介面要高內聚。
-
定製服務。
-
介面設計是有限度的。
衡量規則
:-
一個介面只服務於一個子模組或者業務邏輯。
-
通過業務邏輯壓縮介面中的 public 方法。
-
已經被汙染了的介面,儘量去修改,若變更的風險較大,則採用介面卡模式進行轉化處理。
-
瞭解環境,拒絕盲從。
-
5、迪米特法則
**【Low Of Demeter
】 **
降低耦合,所有的都要解耦。
迪米 特法則就要求類“小氣”一點,儘量不要對外公佈太多的public方法和非靜態的public變數,儘量內斂,多使用private,package-private、protected等訪問許可權。
- 只和朋友交流。
成員朋友類
:出現在成員變數、方法的輸入輸出引數中的類- 朋友間也是有距離的。
- 是自己的就是自己的;如果一個方法放在本類中,即不增加類間關係,也對本類不產生負面影響,就放置在本類中。
- 謹慎使用
Serializable
。
6、開閉原則
**【Open Close Principle
】 **
對擴充套件開放,對修改關閉。
注意:
多用組合,少用繼承。
原因:
- 繼承的時候會破壞封裝
- 組合的好處:類似於裝飾器模式,把裝飾定義在子類或者額外的實現類裡面,通過呼叫不同的方法、動作,來去裝飾。
Java單繼承多實現,為什麼不可以多繼承?
如果是多繼承,子類呼叫父類的名字相同的變數和方法的時候,會出現混淆,就會不知道具體呼叫的哪個父類的方法了,所以必須要單繼承。