SOLID原则：SRP单一职责

可视化演示

展示单一职责原则的核心思想、违反信号检测与重构策略，交互切换查看类拆分前后的职责分布与指标变化。

单一职责本质：一个类只因一个理由而变

小餐厅老板身兼数职的故事，是理解 SRP 最好的入口。他既管炒菜又管收银，菜单一改动，他要同时改菜谱和收银价格；支付平台一升级，他又要重新学操作。这种“牵一发动全身”的窘境，正是软件世界里职责混乱的缩影。

在面向对象中，“类”就相当于餐厅里的“岗位”。如果某个类同时承担多个角色，例如一个 Order 类既算金额、又发通知、还处理支付，那么任何一方的需求变化都会引起这个类被修改。罗伯特·马丁提出，一个类应该只因为一个变化理由而修改。这里的“职责”不是功能，而是“变化的原因”。

用集合语言可以更精确地描述。设 Reasons(C) 为引起类 C 修改的所有原因集合。若集合中有多个元素，说明这个类被多条变化轴线牵动。SRP 要求这个集合的大小为 1。

就像餐厅老板不再既改菜又改账，每个岗位只对一类变化负责。一个类也只因一个原因被修改，这就是“单一职责”的本质。

职责判断标准：看“谁会让你改”

餐厅老板想让收银员顺便开发票，这看起来是加一个“小功能”，但收银员从此要同时关心“支付方式”和“发票格式”。这两件事可能由不同部门决定，未来会分别变化。让一个人同时管两件事，表面高效，实则是下次改动的定时炸弹。

如何判断两个功能是否属于同一职责？不是看动作是否相同，而是看“谁会要求你改”。如果有两个不同角色或两组不同的业务规则都有可能修改这个类，那么职责就不单一。判断标准包含三条：看变化原因是否属于同一维度、看是否对应同一业务实体边界、看是否按角色而非动词切分。

用逻辑公式表达就是：如果存在两个不同的原因都落在同一个类里，这个类就违反了 SRP。公式如下：

判断职责就像排班表：如果同一岗位要听两个经理指挥，遇到双方同时改要求时一定出乱子。让一个岗位只服务一个“变化经理”，才是 SRP 的初衷。

订单处理示例：把大餐厅拆成专业岗位

餐厅接到订单后，老板要确认菜品、算钱、叫外卖员、通知顾客。如果所有事都写进老板的“大脑”，改任何一件事都要翻整本手册。更聪明的做法是设立订单专员、收银员、传菜员，各司其职。

经典的订单处理场景正是 SRP 的教科书。一个设计不当的 Order 类可能包含订单基本信息、金额计算、支付逻辑、消息通知。这四类变化原因完全不同：订单信息字段变化、促销规则变化、支付渠道变化、通知文案变化。

拆分后，用三个类分别承担“订单状态管理”“支付处理”“通知发送”，原来的 Order 只保存必要信息。把原类的方法集合 M 划分为互不重叠的三个子集，每个子集对应一个职责：

拆分后，改支付渠道只碰支付类，改通知模板只碰通知类。就像餐厅改菜谱只通知厨师，收银台不会跟着翻新。这就是 SRP 在订单业务中的落地。

过度拆分反模式：拆成碎片的“一人餐厅”

过度拆分是另一个极端。老板为了“专人专用”，让一个人只洗菜、一个人只切葱、一个人只递盐，炒一个菜需要五个人轮流转。沟通成本比做菜本身还高，出菜速度反而更慢。

SRP 并不等于“类越细越好”。把 Order 类拆成 OrderIdHelper、OrderItemAdder、OrderAmountGetter 等碎屑类，每个类只有一个方法，却要互相依赖传参。这种“碎片化”让系统不仅没变清晰，反而更难以阅读和维护。

反模式有三种常见形态：上帝类（一个类包揽所有职责）、细粒度碎片（把一件事拆得七零八碎）、名词过度切分（为了建模切出大量意义含糊的小类）。总成本公式可以刻画这个问题：

餐厅的岗位不是越细越好。真正的 SRP 是在“一人多职”和“多人一职”之间找到平衡，让每个岗位有明确边界且不冗余，而不是为了拆而拆。

内聚与平衡：让每个岗位有事做但不过细

好的岗位划分就像餐厅的动线：厨房里的人专心做菜，前台的人专心接待。同岗位的人配合紧密，不同岗位之间只需要简单的交接单。这种“内部紧密、外部简洁”的状态，就是软件设计中追求的高内聚、低耦合。

内聚度衡量一个类内部的方法是否围绕相同的职责。一个类如果所有方法都在处理订单价格，内聚度就高；如果一半方法处理价格、另一半处理物流，内聚度就被稀释了。定义内聚度为“围绕同一职责的方法数”与“类中总方法数”之比：

餐厅里，内聚是“同一岗位动作合拍”，低耦合是“不同岗位只需递一张单子”。SRP 正是在这种平衡中让系统既清楚又高效。

架构设计价值：小改动不再惊动全店

当餐厅菜谱改革时，只需要厨师研究新配方，其他岗位照常运转。改动的冲击波被岗位边界挡住了，不会全店停工。这一画面，正是 SRP 在软件架构中价值的生动写照。

职责分离的类更容易被独立测试、替换和复用。在 AI 工程中，数据清洗、特征工程、模型推理、服务发布各司其职，才能支撑频繁迭代。SRP 也是其他 SOLID 原则的基础：因为类只因一个原因修改，扩展新功能时更容易做到对修改关闭；因为关注点被分离，并发场景下可以独立扩容计算密集模块。

从量化角度看，变更影响范围可以描述为：

餐厅因岗位清晰而抗变动，软件因职责单一而可演进。SRP 不是纸上谈兵，而是让 AI 系统在快速变化的数据和需求中站稳脚跟的工程基石。

AI 应用场景

Python 演示

# -*- coding: utf-8 -*-class Order:    def __init__(self, order_id, items, amount):        self.order_id = order_id        self.items = items        self.amount = amount        self.status = "created"     def add_item(self, item, price):        self.items.append(item)        self.amount += price     def get_total(self):        return self.amount class PaymentProcessor:    def pay(self, order, method):        if method == "credit":            print(f"Pay {order.amount} by credit card")        elif method == "alipay":            print(f"Pay {order.amount} by alipay")        order.status = "paid" class NotificationService:    def send(self, order, message):        print(f"Notify {order.order_id}: {message}") class OrderProcessor:    def __init__(self, payment, notifier):        self.payment = payment        self.notifier = notifier     def process(self, order, method):        self.payment.pay(order, method)        self.notifier.send(order, "order paid") if __name__ == "__main__":    order = Order("A001", [], 0)    order.add_item("coffee", 30)    order.add_item("cake", 45)    processor = OrderProcessor(PaymentProcessor(), NotificationService())    processor.process(order, "alipay")    print(order.status)

1. class Order:订单类只负责订单基本信息与金额统计。
2. def pay(self, order, method):支付处理器只关心支付动作，不关心订单如何展示。
3. order.status = "paid"支付完成后通过最小接口修改状态，职责间只传递必要信息。
4. class OrderProcessor:协调器把三个职责连接起来，自己不写具体逻辑。
5. if __name__ == "__main__":可执行入口，演示组合流程。

常见误区

面试题