今天我们来聊一聊设计原则中的单一职责,还是按照惯例,先介绍一下含义,然后呢,我们再来讲一个小故事。
单一职责(SRP:Single Reposibility Principle)的定义:
一个类或者模块只负责完成一个职责。
今天登场的主角,是一个叫阿明的小老板,他从小就经商,很有头脑。他经营着一家月饼店,当然,这家月饼店,也是从他祖父那一辈传下来的。
他家月饼品质很好,干净卫生、用料考究、童叟无欺,所以整个镇子里的人都爱去他家买月饼。随着互联网的发展,他家的月饼名声已经不局限于当地小镇了,国内其他地区的订单也越来越多。
产量严重不足!这是一个让阿明焦虑且急需解决的问题。但是,月饼从和面
、制馅
、包馅
、成型
、烘焙
这一系列操作流程中,每一个环节都很重要,所以要培养一名合格的月饼工人培训周期大概也需要3个月左右,并且还会有一批不符合上岗能力的人被淘汰掉,这可就成为了限制阿明公司发展的障碍了。
那该怎么办呢?正在他愁眉不展的时候,他的高中同学,现在大学任教的小明给他一个建议,为什么要让一个月饼工人把所有操作环节都学会呢?为什么不每个人只专注一种工作?
“哎?对呀!”,这样每个人只学会一项技能,不仅仅培训时间更短了,而且学习难度也大大减小了。然后阿明就招收了100
名年轻人,做出了如下安排:
20
人去学和面20
人去学制馅20
人去学包馅20
人去学成型20
人去学烘焙按照这种安排,原本要学习3个月的培训时间被缩短为2周,而且由于只学习一种能力,几乎没有人被淘汰!
就这样,阿明的流水线工厂也建立起来了!大家干得热火朝天,阿明的月饼供销全国,成为了远近闻名的企业家。
通过上面的一个故事,大家可以看到,从之前一个员工要负责和面
、制馅
、包馅
、成型
、烘焙
这一系列流程操作,到后来只负责其中的一件事,这其实就是单一职责原则了。
除了可以提高生产力之外,还有一个非常重要的点就是——可替换性;我们假设其中有某位工人要离职不干了,那么他之前是负责包馅的,我们只需要再培训一个包馅的员工补充上去即可。而如果是一个全流程都要负责的员工离职了,这个培训和替换的代价就非常大了。
其实在我们开发和架构上,也是这样的。从之前的单体架构,再到现在的微服务架构,我们会发现,服务的粒度越来越小,这样的主要好处就是,如果某个“微服务”出现了异常或者需要升级替换,对整个系统的影响也不会很大。
我们再举一个例子,比如我们家里配了一个台式机,之前呢,就是有上网和看电影的需求而已,后来呢,我们发现,新出了一款3A大作游戏,特别好玩,但是我们电脑的配置运行不了这款游戏,那我们该怎么办呢?重新买一台电脑吗?大可不必~ 我们其实只要针对显卡进行升级即可(买一块高性能的显卡,替换旧的显卡),这样,就可以满足我们玩3A大作的需求了。
每个电脑组件各司其职。如果要升级,可以针对某一模块组件升级,而不用影响到整台电脑。而且是基于接口开发,可以扩展更换不同的实现类。
所以,综上所述,接口一定要尽量做到单一职责。类的设计不应该大而全,要设计粒度小、功能单一的类。如果一个类中存在多个不相干的功能,那么我们就违背了单一职责原则,应该将它拆分成多个功能单一、粒度更新的类。
今天的文章内容就这些了
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。