单一职责原则在C++中是必须遵守的现实约束，类承担多于一个可独立变化的逻辑会导致编译依赖加重、测试困难和连锁故障；判断依据是是否存在多个因不同原因、由不同人、在不同时间修改的部分；常见拆分方式包括将数据、验证、计算、日志等职责分离为独立类，并避免头文件隐式依赖和过早抽象。
单一职责原则（SRP）在 C++ 里不是“要不要用”的问题，而是“不拆就很快会出事”的现实约束——类一旦承担两个以上可独立变化的逻辑，编译依赖变重、单元测试难写、改一个功能带崩另一个，几乎必然发生。
怎么判断一个类违反了 SRP
看它有没有多个“可能被不同人、在不同时间、因不同原因修改”的部分。典型信号包括：
- 类里同时出现
saveToFile()和calculateTotal()这类明显属于不同域的函数 - 头文件里既包含
#include <fstream>又包含#include <cmath>，还混着业务规则硬编码 - 单元测试里要 mock 文件系统、网络、计算逻辑三套东西才能测通一个方法
- Git 提交记录显示这个类在“加新报表字段”和“换数据库驱动”两次需求中都被改过
C++ 中拆分职责的实操边界
拆不是越细越好，关键看变化点是否正交。常见合理切分方式：
-
Order类只存数据（ID、时间、items），不碰验证、价格、库存 -
OrderValidator负责isValid()，输入const Order&，输出bool，不改原对象 -
PriceCalculator接收const Order&和策略对象（如std::shared_ptr<discountpolicy></discountpolicy>），只返回double - 日志、配置、序列化等横切关注点，用独立类（
Logger、ConfigLoader、JsonSerializer）提供静态或单例接口，避免塞进业务类
注意：不要为“未来可能扩展”提前拆，比如还没接入 Kafka 就抽象出 NotificationSender 接口；等真要换通知渠道时再提取，此时已有两个具体实现（EmailNotifier、SmsNotifier），抽象才有意义。
立即学习“C++免费学习笔记（深入）”；
容易踩的坑：C++ 特有的耦合陷阱
相比其他语言，C++ 的头文件依赖和内存管理会让 SRP 失效得更隐蔽：
- 把
std::ofstream成员直接塞进业务类，导致所有包含该头文件的地方都隐式依赖<fstream>和文件系统 ABI - 用
std::unique_ptr<DatabaseConnection>作为成员，却没把DatabaseConnection的定义移到 cpp 文件里（PIMPL 没做），结果改数据库连接参数就得全项目重编译 - 在
ReportGenerator里直接 newPDFWriter，而不是接收工厂或接口，导致无法在测试中替换为MockPDFWriter - 过度使用友元（
friend class ReportSaver）来绕过封装，实际是职责没理清的补救措施
真正难的不是“知道要拆”，而是识别出哪些变化是独立的——这需要你盯着需求变更记录看两周，找出哪些字段/逻辑/外部依赖最近被谁为什么改过。SRP 的边界，永远长在真实的需求演进路径上，不在教科书里。
