单一职责原则中的“职责”如何定义？结合C#矩形类实例求解

先直接点破核心：单一职责原则（SRP）里的“一个变更原因”，不是指代码层面的细碎修改，而是指驱动修改的业务/领域规则的独立变化源。

先看Rectangle类的计算方法是否违反SRP #

你纠结的“存储宽高”和“计算面积周长”，本质上都是围绕「矩形作为几何实体的核心属性与固有行为」。它们的变更原因是高度绑定的：

• 如果因为业务需求要把宽高的精度从int改成float，计算方法必然要跟着调整；
• 如果哪天（虽然概率极低）几何规则里矩形的面积计算方式有特殊定义调整，存储宽高的逻辑和计算逻辑会一起变更。

这时候把计算方法放在Rectangle类里，完全符合SRP——因为它们共享同一个变更原因：矩形作为几何实体的定义变化。

反过来，拆分出RectangleCalculator的场景，只有当计算逻辑的变更完全独立于矩形实体本身时才有意义：比如你的系统里存在多种面积计算规则（比如普通几何计算、工程换算、税费计算），这时候把计算逻辑抽离，让不同的计算器类对应不同规则，才是符合SRP的设计。

再谈Color属性的变更原因问题 #

增加Color属性是否属于另一个变更原因，取决于你的系统领域：

• 如果是图形渲染、CAD这类系统，颜色是矩形作为「可视化图形元素」的固有属性，和宽高一样属于「图形实体的定义」，这时候修改颜色属性和修改宽高的驱动原因是一致的（都是图形实体的需求变化），不违反SRP；
• 如果是纯几何计算系统，颜色属于和几何定义无关的附加属性，这时候增加颜色的驱动原因是「视觉表现需求」，和「几何实体定义」完全独立，这才是引入了第二个变更原因，违反SRP——这种场景下应该把颜色放到单独的类（比如ShapeVisualProperties）里，通过关联关系和Rectangle绑定。

怎么界定“变更原因”？ #

给你两个实用的判断方法：

1. 从领域模型出发：判断类的所有功能是否属于同一个业务概念的核心范畴。比如Rectangle的核心是「几何矩形」，所有和这个概念直接相关的属性（宽高）、行为（计算面积周长）都属于同一职责；
2. “如果…会不会…”测试：假设修改类的某一部分，会不会导致另一部分必须跟着改？如果两者的修改驱动因素完全独立（比如修改颜色不需要改宽高，修改计算规则不需要改颜色），那就是不同的职责；如果修改A必然要改B，那就是同一职责。

内容的提问来源于stack exchange，提问作者gib65