王爭《設計模式之美》筆記
如何理解「介面隔離原則」?
介面隔離原則的英文翻譯是「 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
