王爭《設計模式之美》筆記
如何理解「介面隔離原則」?
介面隔離原則的英文翻譯是「 Interface Segregation Principle」,縮寫為ISP。意思是:客戶端不應該強迫依賴它不需要的介面。其中的「客戶端」,可以理解為介面的調用者或者使用者。
理解介面隔離原則的關鍵,就是理解其中的「介面」二字。在這條原則中,我們可以把「介面」理解為下面三種東西:
- 一組 API 介面集合
- 單個 API 介面或函數
- OOP 中的介面概念
把「介面」理解為一組 API 介面集合
UserService中添加刪除用戶功能時,新加RestrictedUserService給特定用戶使用。
把「介面」理解為單個 API 介面或函數
把「介面」理解為 OOP 中的介面概念
通過RedisConfig、 MysqlConfig、KafkaConfig的熱更新和在頁面上展示,說明了符合介面隔離原則的代碼:
1.設計思路更加靈活、易擴展、易復用
2.不符合的設計思路在代碼實現上做了一些無用功
重點回顧
1. 如何理解「介面隔離原則」?
理解「介面隔離原則」的重點是理解其中的「介面」二字。這裡有三種不同的理解。
如果把「介面」理解為一組介面集合,可以是某個微服務的介面,也可以是某個類庫的介面等。如果部分介面只被部分調用者使用,我們就需要將這部分介面隔離出來,單獨給這部分調用者使用,而不強迫其他調用者也依賴這部分不會被用到的介面。
如果把「介面」理解為單個 API 介面或函數,部分調用者只需要函數中的部分功能,那我 們就需要把函數拆分成粒度更細的多個函數,讓調用者只依賴它需要的那個細粒度函數。
如果把「介面」理解為 OOP 中的介面,也可以理解為面向對象編程語言中的介面語法。那介面的設計要盡量單一,不要讓介面的實現類和調用者,依賴不需要的介面函數。
2. 介面隔離原則與單一職責原則的區別
單一職責原則針對的是模塊、類、介面的設計。介面隔離原則相對於單一職責原則,一方面更側重於介面的設計,另一方面它的思考角度也是不同的。介面隔離原則提供了一種判斷介面的職責是否單一的標準:通過調用者如何使用介面來間接地判定。如果調用者只使用部分介面或介面的部分功能,那介面的設計就不夠職責單一。
參考:https://time.geekbang.org/column/intro/250?code=gLit0LpsKZQ6vOVqS1htGOSAKYLCYeMuklw2dwajH-4%3D