不知道大家是否看过这样一个短视频——“姐姐去找她的弟弟,因为她的弟弟想要当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^)/ ~ 「干货分享,每天更新」
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。