一、前言

今天我们来聊一聊设计原则中的单一职责，还是按照惯例，先介绍一下含义，然后呢，我们再来讲一个小故事。

单一职责（SRP：Single Reposibility Principle） 的定义：

一个类或者模块只负责完成一个职责。

二、小故事

今天登场的主角，是一个叫阿明的小老板，他从小就经商，很有头脑。他经营着一家月饼店，当然，这家月饼店，也是从他祖父那一辈传下来的。

他家月饼品质很好，干净卫生、用料考究、童叟无欺，所以整个镇子里的人都爱去他家买月饼。随着互联网的发展，他家的月饼名声已经不局限于当地小镇了，国内其他地区的订单也越来越多。

产量严重不足！这是一个让阿明焦虑且急需解决的问题。但是，月饼从和面、制馅、包馅、成型、烘焙这一系列操作流程中，每一个环节都很重要，所以要培养一名合格的月饼工人培训周期大概也需要3个月左右，并且还会有一批不符合上岗能力的人被淘汰掉，这可就成为了限制阿明公司发展的障碍了。

那该怎么办呢？正在他愁眉不展的时候，他的高中同学，现在大学任教的小明给他一个建议，为什么要让一个月饼工人把所有操作环节都学会呢？为什么不每个人只专注一种工作？

“哎？对呀！”，这样每个人只学会一项技能，不仅仅培训时间更短了，而且学习难度也大大减小了。然后阿明就招收了100名年轻人，做出了如下安排：

• 20人去学和面
• 20人去学制馅
• 20人去学包馅
• 20人去学成型
• 20人去学烘焙

按照这种安排，原本要学习3个月的培训时间被缩短为2周，而且由于只学习一种能力，几乎没有人被淘汰！

就这样，阿明的流水线工厂也建立起来了！大家干得热火朝天，阿明的月饼供销全国，成为了远近闻名的企业家。

三、总结

通过上面的一个故事，大家可以看到，从之前一个员工要负责和面、制馅、包馅、成型、烘焙这一系列流程操作，到后来只负责其中的一件事，这其实就是单一职责原则了。

除了可以提高生产力之外，还有一个非常重要的点就是——可替换性；我们假设其中有某位工人要离职不干了，那么他之前是负责包馅的，我们只需要再培训一个包馅的员工补充上去即可。而如果是一个全流程都要负责的员工离职了，这个培训和替换的代价就非常大了。

其实在我们开发和架构上，也是这样的。从之前的单体架构，再到现在的微服务架构，我们会发现，服务的粒度越来越小，这样的主要好处就是，如果某个“微服务”出现了异常或者需要升级替换，对整个系统的影响也不会很大。

我们再举一个例子，比如我们家里配了一个台式机，之前呢，就是有上网和看电影的需求而已，后来呢，我们发现，新出了一款3A大作游戏，特别好玩，但是我们电脑的配置运行不了这款游戏，那我们该怎么办呢？重新买一台电脑吗？大可不必~ 我们其实只要针对显卡进行升级即可（买一块高性能的显卡，替换旧的显卡），这样，就可以满足我们玩3A大作的需求了。

每个电脑组件各司其职。如果要升级，可以针对某一模块组件升级，而不用影响到整台电脑。而且是基于接口开发，可以扩展更换不同的实现类。

所以，综上所述，接口一定要尽量做到单一职责。类的设计不应该大而全，要设计粒度小、功能单一的类。如果一个类中存在多个不相干的功能，那么我们就违背了单一职责原则，应该将它拆分成多个功能单一、粒度更新的类。

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

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

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