持续创作，加速成长！这是我参与「掘金日新计划 · 10 月更文挑战」的第7天，点击查看活动详情
定义
接口隔离原则的英文翻译是“ Interface Segregation Principle”，缩写为 ISP。Robert Martin 在 SOLID 原则中是这样定义它的：“Clients should not be forced to depend upon interfaces that they do not use。”直译成中文的话就是：客户端不应该被强迫依赖它不需要的接口。其中的“客户端”，可以理解为接口的调用者或者使用者。
客户端可以理解成是调用方，调用方不应该依赖他不需要的接口。这个一般是接口中设计的方法不够“单一”（主观需要根据业务来判定），应该将相同功能的方法拆分到一个独立的接口中
“接口”的定义
一组API接口集合
在设计微服务或者类库接口的时候，如果部分接口只被部分调用者使用，那我们就需要将这部分接口隔离出来，单独给对应的调用者使用，而不是强迫其他调用者也依赖这部分不会被用到的接口。
把“接口”理解为单个 API 接口或函数
单个接口中的功能是否足够单一。单一的定义是主观的，需要根据业务来判断。
和单一职责SRP区别
接口隔离原则跟单一职责原则有点类似，不过稍微还是有点区别。单一职责原则针对的是模块、类、接口的设计。 而接口隔离原则相对于单一职责原则，一方面它更侧重于接口的设计，另一方面它的思考的角度不同。它提供了一种判断接口是否职责单一的标准：通过调用者如何使用接口来间接地判定。 如果调用者只使用部分接口或接口的部分功能，那接口的设计就不够职责单一。
ISP从调用者的角度来考虑是否实现了不需要的接口，更侧重于接口设计。而单一职责比较宽泛，涉及的不仅仅是接口，还有类，模块设计。
把“接口”理解为 OOP 中的接口概念
思考需求的时候要想这个行为是否是某个模块/类 公用的行为。如果是单独来做的需要将这部分行为单独抽取出来，在创建一个管理者Manager的类去单独管理这一类通用行为。
目前设计的时候也是这种思路，好处的话就是1. 控制这部分行为的逻辑代码可以抽离不用去关心这些模块/类具有的其他行为。2. 也就是只关心这个行为不关心实现这个行为的具体类，之后修改只需改动这个管理者类的代码即可；也符合接口的设计原则，他实现了这个接口就代表他拥有了这个行为。3.当这个行为也想被其他类使用时只需要实现这个接口即可。
虽然说会比较啰嗦复杂还需要新加多个接口和管理者，但是这种对于之后的需要获取这个行为的类来说关注点只在这个接口，而不需要去强制依赖其他无关接口，。
好处
- 设计思路更加灵活、易扩展、易复用。
- 颗粒度更小，如果一揽子全干的话改动太大。并且之后需要添加扩展的话需要实现所有的方法即使他并不需要这个行为。就类似于人家不会飞你非要给人家安上翅膀哈哈~~
颗粒度越小改动越小，不强迫不需要这个行为的类强制去实现这个行为
