趣解接口隔离原则之《做个Rapper咋这么难？》

〇、小故事

不知道大家是否看过这样一个短视频——“姐姐去找她的弟弟，因为她的弟弟想要当rapper而荒废了学业，姐姐多番劝导也没有用，最后一怒一下，把弟弟的rapper发型剃了。没有了帅气的rapper发型，弟弟也放弃了当rapper的想法了。”

这时候有的同学可能就会问，“扯淡！发型剃掉了就不当rapper了？rapper是靠发型出道的？”嗯，有这种质疑非常好，但是，视频中的弟弟或许就是认为外表照着某些rapper打造，自己就是rapper了呗。其实也不必嘲笑他，估计大家在小的时候，都有过看了某部动画片之后，就去买动画片中主角的周边产品，然后自己就瞬间主角附体了。

那什么才是真正的rapper？这个定义估计在大家的心中也各不相同。比如：

【特征1】说唱功底很厉害<br> 【特征2】唱功也一定要厉害<br> 【特征3】要会freestyle<br> 【特征4】需要自己写词写曲<br> 【特征5】穿衣服一定要又潮又帅<br> 【特征6】要有纹身<br> ……

好，经过大家各抒己见，我们或许最终会收集到大概30个左右的特征，如果跟上面视频中的小伙子说，如果你相当rapper，把这30特征都要达到标准，估计这个小伙子自己就放弃了。“这要当rapper也太难了吧，算了算了，不当了不当了”。

你看看，我想当个rapper，需要满足的条件太多了啊！这还咋当了。那么，如果我们真的要定义一个Rapper接口，我们需要哪些必不可少的能力？

【特征1】说唱功底很厉害 <br> 【特征3】要会freestyle（这条其实可以去掉，因为有的Rapper确实不会freestyle，此处就暂且算上）

那么，如果说相当rapper，只需要满足2个特征，是不是又可以点燃这个小伙子相当Rapper的梦了？ 所以，从以上的故事我们可以得出一个设计原则，那就是针对接口（Rapper）来说，不要设计的过于臃肿（30个特征），只需要包含必要的方法即可（2个特征），否则对于接口的实现者来说，会是一个巨大的负担（小伙放弃当Rapper了）。

一、原则定义

接口隔离原则（ISP：Interface Segregation Principle）

使用多个专门的接口，而不使用单一的总接口，即客户端不应该依赖那些它不需要的接口。

建立单一接口，不要建立臃肿庞大的接口。接口尽量细化，同时接口中的方法尽量少。

单一职责原则和接口隔离的区别？答：它们的审视角度不同。

单一职责要求的是类和接口职责单一，注重的是职责，这是业务逻辑上的划分。<br> 接口隔离原则要求接口的方法尽量少。

具体来说，实现接口隔离原则需要关注以下3点：

【接口要尽量小】不要违反单一职责原则，要适度的小，要适度。<br> 【接口要高内聚】提高接口、类、模块的处理能力，减少对外的交互。<br> 【定制服务】通过对高质量接口的组装，实现服务的定制化。

二、原则实践

以上面为例，我们最初设想的Rapper接口需要具有以下特征：

【特征1】说唱功底很厉害<br> 【特征2】唱功也一定要厉害<br> 【特征3】要会freestyle<br> 【特征4】需要自己写词写曲<br> 【特征5】穿衣服一定要又潮又帅<br> 【特征6】要有纹身<br> ……

那么，我们可以将相关的特征抽象为不同的接口，例如：

• 接口Rapper

【特征1】说唱功底很厉害 <br> 【特征4】需要自己写词写曲

• 接口Singer

【特征2】唱功也一定要厉害 <br> 【特征4】需要自己写词写曲

• 接口FashionMan

【特征5】穿衣服一定要又潮又帅 <br> 【特征6】要有纹身

这样的话，实现不同特性的Rapper，也可以通过实现多个接口的方式，来组合出相应的Rapper了。

今天的文章内容就这些了：

写作不易，笔者几个小时甚至数天完成的一篇文章，只愿换来您几秒钟的 点赞 & 分享 。

更多技术干货，欢迎大家关注公众号“爪哇缪斯” ~ \(^o^)/ ~ 「干货分享，每天更新」