什么是单一职责原则？
单一职责原则（Single Responsibility Principle, SRP）是面向对象设计五大原则（SOLID）中的第一个原则。它指出：
一个类应该只有一个引起它变化的原因 （A class should have only one reason to change）
换句话说，一个类应该只负责一项职责，如果一个类承担了多个职责，那么这些职责就会耦合在一起，导致类的复杂度增加、维护困难、测试困难等问题。
核心思想
- 职责分离：将不同的功能或责任分配到不同的类中。
- 高内聚：每个类内部的代码高度相关，专注于一个任务。
- 低耦合：类之间依赖关系最小化，减少相互影响。
为什么需要单一职责原则？
1. 提高代码可维护性
- 当一个类负责多个职责时，修改一个职责可能会影响另一个职责的实现。
- 例如：一个类既处理订单逻辑，又处理日志记录。如果修改订单逻辑，可能意外破坏日志功能
2. 增强可复用性
- 单一职责的类更容易被其他模块复用。
- 例如：日志记录模块可以独立复用到其他系统中。
3. 降低耦合度
- 类之间依赖关系减少，系统更灵活，更易扩展。
4. 简化测试
- 单一职责的类更容易编写单元测试，减少测试用例的复杂性。
举例说明
❌ 违反单一职责原则的示例
cpp
class OrderProcessor {
public:
void processOrder(const Order& order) {
// 1. 处理订单逻辑
calculateTotal(order);
applyDiscount(order);
saveToDatabase(order);
// 2. 发送邮件通知
sendEmail(order.customerEmail, "Your order is processed.");
}
private:
void calculateTotal(const Order& order) { /* ... */ }
void applyDiscount(const Order& order) { /* ... */ }
void saveToDatabase(const Order& order) { /* ... */ }
void sendEmail(const std::string& email, const std::string& message) { /* ... */ }
};问题：
OrderProcessor类既负责订单处理，又负责发送邮件。- 如果邮件系统需要修改，必须修改
OrderProcessor类，可能影响订单处理逻辑。
✅ 遵循单一职责原则的改进
cpp
// 职责1：订单处理
class OrderProcessor {
public:
void processOrder(const Order& order) {
calculateTotal(order);
applyDiscount(order);
orderDatabase.save(order);
}
private:
void calculateTotal(const Order& order) { /* ... */ }
void applyDiscount(const Order& order) { /* ... */ }
OrderDatabase orderDatabase;
};
// 职责2：邮件发送
class EmailService {
public:
void sendOrderConfirmation(const Order& order) {
sendEmail(order.customerEmail, "Your order is processed.");
}
private:
void sendEmail(const std::string& email, const std::string& message) { /* ... */ }
};改进：
OrderProcessor只负责订单处理。EmailService独立负责邮件发送。- 两者通过依赖注入（如
orderDatabase）协作。
如何判断职责是否单一？
判断一个类是否满足单一职责原则，可以从以下角度考虑：
| 判断标准 | 说明 |
|---|---|
| 变化原因 | 一个类是否因为多个不同的原因需要修改？ |
| 功能相关性 | 类中的方法是否都围绕同一主题？ |
| 依赖关系 | 类是否依赖多个其他类？ |
| 可测试性 | 是否能为类编写独立的单元测试？ |
实际应用场景
1. 订单系统
- 订单处理类：负责订单计算、折扣、库存检查。
- 日志记录类：负责将订单操作记录到日志。
- 邮件服务类：负责发送订单确认邮件。
2. 用户管理
- 用户认证类：负责用户登录、权限验证。
- 用户数据类：负责用户信息存储和查询。
3. 支付系统
- 支付处理类：负责支付逻辑（如支付宝、微信）。
- 支付记录类：负责保存支付日志。
单一职责原则与其他原则的结合
| 原则 | 与 SRP 的关系 |
|---|---|
| 开闭原则 (OCP) | 单一职责的类更容易扩展（如新增支付方式） |
| 依赖倒置原则 (DIP) | 通过接口依赖实现职责分离 |
| 接口隔离原则 (ISP) | 为不同职责定义独立接口 |
| 迪米特法则 (LoD) | 降低类之间直接依赖，减少职责耦合 |
常见误区
| 误区 | 说明 |
|---|---|
| 过度拆分 | 将职责拆分过细导致类数量爆炸，增加维护成本。 |
| 职责边界模糊 | 业务逻辑中"职责"是业务概念，不是技术概念。例如，"订单处理"是一个职责，但"计算价格"和"保存到数据库"是其中的子职责。 |
| 忽视协作 | 单一职责的类需要通过协作完成复杂任务，不是完全独立。 |
总结
| 原则 | 说明 |
|---|---|
| 单一职责原则 (SRP) | 一个类应该只负责一项职责 |
| 核心目标 | 提高可维护性、可复用性、可测试性 |
| 关键点 | 高内聚、低耦合、职责分离 |
| 应用场景 | 复杂系统、需要长期维护的项目 |
应用建议
- 识别职责：分析业务需求，明确每个类的职责边界。
- 拆分大类：当一个类包含多个不相关的方法时，考虑拆分。
- 依赖注入：通过接口或依赖注入实现类间协作。
- 持续重构：在代码迭代中不断优化职责划分。
✅ 示例：正确应用 SRP 的代码
cpp
// 职责1：订单处理
class OrderProcessor {
public:
void processOrder(const Order& order) {
calculateTotal(order);
applyDiscount(order);
orderDatabase.save(order);
}
private:
void calculateTotal(const Order& order) { /* ... */ }
void applyDiscount(const Order& order) { /* ... */ }
OrderDatabase orderDatabase;
};
// 职责2：邮件发送
class EmailService {
public:
void sendOrderConfirmation(const Order& order) {
sendEmail(order.customerEmail, "Your order is processed.");
}
private:
void sendEmail(const std::string& email, const std::string& message) { /* ... */ }
};通过单一职责原则，系统会更加清晰、灵活，易于维护和扩展。