一个类只能有一项职责，即仅有一个引起它变化的原因；例如Logger类若新增配置加载逻辑，就因配置路径变更和日志规则变更两个原因需修改，违反SRP；应拆分为Logger、ConfigLoader等各司其职的类，通过组合协作。
一个类应该只承担一项职责——不是“尽量少”，而是“只能有一项”。这不是风格偏好，而是可维护性的硬边界。
怎么判断职责是否单一
看这个类修改的触发条件是否只有一个。比如：Logger 类，只有日志格式、输出目标、级别过滤规则变化时才需要改它；如果某天还要在里头加配置加载逻辑，那配置文件路径一变，Logger 就得动——这就引入了第二个变化原因，违反了单一职责。
- 常见错误现象：一个类里同时出现
readConfig()、writeLog()、saveToFile()，且三者共享成员变量或状态 - 使用场景：封装日志模块时，
Logger只管写；ConfigLoader只管读；FileManager只管打开/关闭/校验路径 - 参数差异：
Logger::log(const std::string& msg, LogLevel level)和ConfigLoader::load(const std::string& path)的参数语义完全不同，混在一起只会让接口模糊
拆分后怎么协作
靠组合，不靠继承，也不靠全局访问。比如 Application 类需要记日志又需要读配置，就该持有 std::unique_ptr<logger></logger> 和 std::unique_ptr<configloader></configloader>，而不是自己实现这两套逻辑。
- 性能影响：组合引入的间接调用开销几乎为零（现代编译器能内联大部分简单委托）
- 兼容性影响：拆分后各模块可独立单元测试，
Logger换成异步队列实现，不影响ConfigLoader的任何调用方 - 容易踩的坑：用
friend打破封装来“方便协作”，结果把两个类的内部细节耦合得比继承还紧
什么情况下可以放宽
仅当多个行为天然不可分割、且永远同步变更——例如 Point2D 类同时存 x 和 y，改坐标系就得一起动，这不是多职责，而是同一职责的两个必要组成部分。
立即学习“C++免费学习笔记（深入）”；
- 反例：
DatabaseConnection里塞 SQL 构建、结果集解析、连接池管理——三者变化原因完全不同 - 真实约束：C++ 没有语言级的“职责检查”，全靠设计者识别“引起变化的原因”。这恰恰是最容易被忽略的地方：不是代码能不能跑，而是下次需求变更时，你敢不敢只改一个文件？
