底层原理之“单一职责”原则

单一职责原则（Single-Responsibility Principle，SPP）是计算机领域程序设计原则中一个非常重要的原则。通过思考分析可以发现，该原则的应用绝不仅仅只是计算机程序设计，而是适用于许多问题研究。 
本文将：
从程序设计中的设计原则讲起，介绍单一职责原则的含义（关于“是什么/WHAT”的问题）； 
该原则能应用到日常的很多场景（关于“在哪里/WHERE”的问题）； 
简单分析为什么要遵循单一职责原则（关于“为什么/WHY”的问题）； 
介绍我们如何能遵循单一职责（关于“怎么样/HOW”的问题）； 
下面我们将对这四部分内容进行介绍。 
1.什么是单一职责原则？（WHAT） 
在计算机科学中，单一职责原则的原话是： 
一个类应该只有一个变化的原因
原话是比较难理解的，但我们可以采用另外一种说法（Wiki）： 
一个模块应该只对一个，且仅对一个行为者负责
这句话是有三个核心词语：模块、行为者、一个且仅一个。这里分别对这三个词进行简单解析。 
模块：是一个抽象的概念，对应到代码里，可以是微服务、包、类、方法、变量等； 
行为者：是指需要模块协助以完成某项任务、目标的主体，可以由一个或多个利益相关者或调用方组成； 
一个且仅一个：是指一个模块对外提供的职责唯一，有且仅有一个。模块的职责和行为者之间是一对一的关系（如图1），而不能是一对多、多对一、多对多的关系。也就是说，一个职责也不能够分散到多个模块中。 
![](/media/202406/2024-06-25_092515_196876.png)
图1 单一职责原则 
经过以上分析，一个模块应该是对外（行为者）提供一个特定职责或功能。这样才能够做到，模块之间才能解耦，互相能够做到“高内聚、低耦合”。 
有朋友可能会疑问，模块是可以有大有小，可以分层的，怎么和职责对应呢？其实，职责也是可以有大有小的，可以逐层细分的。 
需要多提一下的是，模块的职责是可能会随着时间发生演化变更的。 
2.“单一职责原则”无处不在（WHERE） 
其实，“单一职责原则”不仅仅在程序设计中被采用。它在我们组织、生活、工作等中也能经常看到。 
2.1 组织架构 
在各种组织架构（政府、企业等）中，同一层的组织互相之间应该是“单一职责”的。 
在我国政府机构中，同一层的部门/局一定是职责单一、边界清晰的。例如，GW院下有教育部、外交部、国防部、司法部等，这些部门的职责都是很清晰的且独立的。
如教育部就是专门管教育相关的，而不会关注法律相关的范围；高考政策制定也不归外交部管。 
类似地，在企业中，同一层级的部门、组之间也应是职责单一、边界清晰的。 
2.2 城市土地使用分区 
现代城市建设会根据每一个地理区域的特点和位置定位成不同土地使用分区，如：住宅区、办公区、商业区、工业区、绿化区等（如图2）。这些区域都会有自己的职责和功能。
比如说，在办公区的办公室烧火生饭就会觉得让人觉得不和谐。 
![](/media/202406/2024-06-25_092438_590550.png)
图2 某地区的土地使用分区（来自网络）
2.3 住宅空间功能分区 
我们的家也是按照空间职责进行划分的。例如，我们的家会有：厨房、餐厅、客厅、卧室、阳台等空间。
这些空间都是有自己的核心功能；厨房就是我们做饭的地方；餐厅就是我们吃饭的地方。一般情况下，我们不会在厨房会客，不然的话，主客都会觉得很奇怪。 
2.4 加工厂生产流水线 
在加工厂的流水线上，一般会有很多个阶段/区域/工作点。每一个区域就是有专门负责的事情。
例如，一个完成的加工流水线应该有：原材料准备、加工制造、质量检查、包装、出货等。在流水线上，每一个阶段都有自己的职责，而不能够跨越职责。 
2.5 电商网站的领域拆分 
在电商网站领域，为了支持买家从卖家中购买商品，整个电商网站应该至少需要以下子领域：卖家、卖家、商品、订单、支付、物流等领域。这些领域之间要求是职责单一的，且互相隔离的。
例如，下单的功能在订单领域，而取消订单则在商品领域，这是违背了职责单一的原则的，会造成系统混乱。 
以上是一些职责单一常见的场景。其实，单一职责场景远不止这些。 
例如，生物科研领域分为七个层级：界、门、纲、目、科、属、种。这里的每一层的划分也都是满足职责单一原则的。在生物学上，分类和命名甚至有“法规”去规定，可见生物学上对分类和命名是极其严格的，也就是对每一个类目的职责范围是非常明确的。
个人觉得，生物学研究对命名有这么严格的要求应该是：命名反映了定义，而定义反映了认知（或：认知决定了定义，定义决定了命名）。
动物和植物分类学界各自制订了《命名法规》，具体如下：“分类名称要求稳定，一个属或种(包括种下单元)只能有一个学名。一个学名只能用于一个对象(或种)，如果有两个或多个对象者，便是“异物同名”，必须于其中核定最早的命名对象，而其他的同名对象则另取新名。
3.为什么要遵循 单一职责原则？（WHY）
我们可以采用“反证法”进行阐述。假如，模块的职责不单一，那么可能会存在哪些问题呢？
3.1 模块定义不清晰
例如，我们把家里的厨房用作两个职责：可以做饭，也可以睡觉。当然我们可以这么做，这就需要在厨房上摆放各种厨具的同时，也要放上一张床。但是这样厨房的定义是不清晰的，或者说，它还是一个厨房吗？ 
3.2 职责边界不清晰
在上一个例子中，先不考虑厨房能不能够放下各种厨具和床。假如能够放下，我相信大部分人都愿意增加一面墙以区分做饭和睡觉的地方。这面墙就是职责“边界”。如果没有这面墙，那么做饭和睡觉的边界是没有明确的，是不清晰的。
3.3 职责混乱
更严重的是，同一个职责存在于多个模块中，那么就会造成职责混乱。在程序代码中，对于一个需求、多个模块都可以支持，那么不知道应该放在哪里。 
例如，在某公司中，假如发票报销可以在两个不同大部门进行，那么员工就会很困惑，不知道应该找谁进行报销；甚至可能，两个部门互相踢皮球，都不提供服务。 
3.4 增加理解成本
不管是一个职责存在于多个模块，或者一个模块有多个职责，都会增加理解成本，都需要更多的精力去理解。
例如，我们有N个模块和N个职责，如果这些模块都是有单一职责的，那么模块和职责之间就只存在N组关系；而如果是多对多的关系，那么就可能存在N * N组关系（如图4）。这是不同级别的复杂度，理解成本也对应地提升。
![](/media/202406/2024-06-25_092346_101967.png)
图4 一对一与多对多的复杂度 
以上只是列举了模块的职责不单一部分问题，它还会存在很多其他问题，如：增加维护成本、有更高易错性等。这里将不一一阐述。 
因为违背“职责单一原则”有很多问题，因此，维护模块的“单一职责”很重要。 
4.怎么样能做到单一职责？（HOW）
那么，我们要怎么做到单一职责呢？
核心思想是基于分类法的结构化思维。分类法是一种将对象或事物根据其特征和属性划分为不同类别的方法。 
在应用分类法时，一定是按照某一个维度进行拆分的（不同类别不能够按照不同维度进行分类）；切要保证“不重不漏”（Mutually Exclusive, Collectively Exhaustive，MEMC）原则。 
例如，按照空间功能可以将家拆分成：厨房、餐厅、客厅、卧室、阳台等空间。但如果将家拆分成：厨房、餐厅、洗衣机、晾衣架、卧室等。这就不是一个合理的拆分，因为后者就是没有按照一个维度进行展开的，洗衣机和餐厅不具有同一个层级的职责，造成类别混乱。 
分类法可以自上而下或自下而上进行。这里主要介绍一下自上而下的划分方式。具体来说，要自上而下一个合理拆分，可以采用以下步骤：
1）理清全局。在分类之前，需要理清当前领域（层级）下的所有功能、事项、流程等；
2）选择拆分维度。选择一个合适的拆分维度，常见的拆分维度有：
按功能进行拆分，例如，组织架构；
按照物理空间进行拆分，例如：城市土地使用分区，住宅空间功能分区；
按照流程（时间）拆分，例如：加工厂生产流水线；
按成分或组件拆分，例如，汽车是由多个不同的组件组装而成等。
按其他特征拆分，如：渠道；
3）进行拆分。利用MECE原则按照选定的维度对整体进行拆分。使拆分后的模块“不重不漏”，每一个子模块有一个清晰的定义和职责。
此外，在实际拆分时，可以按照研究的具体问题进行适合问题的拆分。
5.总结
本文的主要内容（知识架构）如图5所示。“单一职责原则”是计算机科学中“系统设计的”一个重要原则。但该原则在其他领域中也是适用的。
“单一职责原则”很重要；如果在问题分析、方案设计时，模块不满足该原则，则可能会引入很多问题。因此，我们在分解模块时需要按照正确的分类法，以确保子模块的职责单一。
![](/media/202406/2024-06-25_092252_019643.png)
图5 职责单一原则知识架构