〇、小故事
不知道大家是否看过这样一个短视频------"姐姐去找她的弟弟，因为她的弟弟想要当rapper而荒废了学业，姐姐多番劝导也没有用，最后一怒一下，把弟弟的rapper发型剃了。没有了帅气的rapper发型，弟弟也放弃了当rapper的想法了。"
这时候有的同学可能就会问，"扯淡！发型剃掉了就不当rapper了？rapper是靠发型出道的？"嗯，有这种质疑非常好，但是，视频中的弟弟或许就是认为外表照着某些rapper打造，自己就是rapper了呗。其实也不必嘲笑他，估计大家在小的时候，都有过看了某部动画片之后，就去买动画片中主角的周边产品，然后自己就瞬间主角附体了。
那什么才是真正的rapper？这个定义估计在大家的心中也各不相同。比如：
【特征1 】说唱功底很厉害
【特征2 】唱功也一定要厉害
【特征3 】要会freestyle
【特征4 】需要自己写词写曲
【特征5 】穿衣服一定要又潮又帅
【特征6 】要有纹身
......
好，经过大家各抒己见，我们或许最终会收集到大概30个左右的特征 ，如果跟上面视频中的小伙子说，如果你相当rapper，把这30特征都要达到标准，估计这个小伙子自己就放弃了。"这要当rapper也太难了吧，算了算了，不当了不当了"。
你看看，我想当个rapper，需要满足的条件太多了啊！这还咋当了。那么，如果我们真的要定义一个Rapper接口，我们需要哪些必不可少的能力？
【特征1 】说唱功底很厉害
【特征3】要会freestyle（这条其实可以去掉，因为有的Rapper确实不会freestyle，此处就暂且算上）
那么，如果说相当rapper，只需要满足2个特征，是不是又可以点燃这个小伙子相当Rapper的梦了？ 所以，从以上的故事我们可以得出一个设计原则，那就是针对接口（Rapper）来说，不要设计的过于臃肿（30个特征），只需要包含必要的方法即可（2个特征），否则对于接口的实现者来说，会是一个巨大的负担（小伙放弃当Rapper了）。
一、原则定义
接口隔离原则（ISP：Interface Segregation Principle）
使用多个专门的接口，而不使用单一的总接口，即客户端不应该依赖那些它不需要的接口。
建立单一接口，不要建立臃肿庞大的接口。接口尽量细化，同时接口中的方法尽量少。
单一职责原则和接口隔离的区别？答：它们的审视角度不同。
单一职责要求的是类和接口职责单一 ，注重的是职责 ，这是业务逻辑上的划分。
接口隔离原则要求接口的方法尽量少。
具体来说，实现接口隔离原则需要关注以下3点：
【接口要尽量小 】不要违反单一职责原则，要适度的小，要适度。
【接口要高内聚 】提高接口、类、模块的处理能力，减少对外的交互。
【定制服务】通过对高质量接口的组装，实现服务的定制化。
二、原则实践
以上面为例，我们最初设想的Rapper接口需要具有以下特征：
【特征1 】说唱功底很厉害
【特征2 】唱功也一定要厉害
【特征3 】要会freestyle
【特征4 】需要自己写词写曲
【特征5 】穿衣服一定要又潮又帅
【特征6 】要有纹身
......
那么，我们可以将相关的特征抽象为不同的接口，例如：
- 接口
Rapper
【特征1 】说唱功底很厉害
【特征4】需要自己写词写曲
- 接口
Singer
【特征2 】唱功也一定要厉害
【特征4】需要自己写词写曲
- 接口
FashionMan
【特征5 】穿衣服一定要又潮又帅
【特征6】要有纹身
这样的话，实现不同特性的Rapper，也可以通过实现多个接口的方式，来组合出相应的Rapper了。
今天的文章内容就这些了：
写作不易，笔者几个小时甚至数天完成的一篇文章，只愿换来您几秒钟的 点赞 & 分享 。
更多技术干货，欢迎大家关注公众号"爪哇缪斯" ~ \(^o^)/ ~ 「干货分享，每天更新」