单一职责原则（Single Responsibility Principle，简称SRP）是面向对象编程五大设计原则SOLID中的第一个原则，它的核心定义是一个类应该只有一个引起它变化的原因，简单来说就是每个类只负责一项具体的功能，不要把多个不相关的职责放到同一个类中。
单一职责原则的核心含义
要理解单一职责原则，首先要明确什么是类的职责。类的职责指的是这个类所承担的具体功能，比如用户类可能负责用户信息的管理，订单类可能负责订单相关的操作。如果一个类同时承担了两个以上的职责，就违反了单一职责原则。
举个例子，一个User类如果同时负责用户信息的存储和用户数据的校验，那么当用户存储逻辑需要修改，或者用户校验规则需要修改的时候，这个User类都需要跟着变化，这就说明它有了两个引起变化的原因，不符合单一职责原则的要求。
违反单一职责原则的问题
很多开发者在初期写代码的时候会觉得把相关功能放到一个类里更方便，但是随着项目迭代，违反单一职责原则会带来很多明显的问题：
- 代码复杂度升高：一个类里堆了太多功能，方法的逻辑会变得混乱，后续阅读代码的时候很难快速理清每个部分的作用。
- 维护成本增加：修改其中一个功能的时候，很容易不小心影响到其他不相关的功能，引发意料之外的bug。
- 复用性变差：其他模块如果需要复用其中某一个功能，不得不引入整个类，可能会带上很多不需要的依赖。
- 测试难度变大：测试的时候需要覆盖类的所有职责，测试用例会变得繁琐，也容易遗漏测试场景。
OOP开发中类功能拆分的实践方法
在实际的OOP开发中，我们可以通过以下步骤来拆分类的功能，落实单一职责原则：
1. 识别类的现有职责
首先梳理当前类中所有的方法，把功能相似的方法归为一组，每一组就对应一个潜在的职责。比如一个OrderService类里有创建订单、计算订单金额、发送订单通知、保存订单到数据库的方法，那可以初步分为订单业务处理、订单通知、订单持久化三个职责组。
2. 拆分职责到独立的类
把每个职责组对应的方法拆分到单独的类中，每个新类只负责对应的职责。比如上面的OrderService可以拆分为：
OrderManager：负责订单的创建、金额计算等核心业务逻辑OrderNotifier：负责订单相关通知的发送OrderRepository：负责订单数据的持久化操作
3. 调整类之间的依赖关系
拆分之后，原来的类如果需要用到其他职责的功能，可以通过依赖注入的方式引入对应的类，而不是直接在内部实现相关逻辑。下面是拆分后的代码示例：
// 订单实体类，只负责存储订单基本信息
class Order {
private String orderId;
private double amount;
private String userId;
// 构造方法和getter、setter省略
}
// 订单业务逻辑类，只负责订单相关的业务处理
class OrderManager {
// 计算订单金额
public double calculateAmount(Order order) {
// 假设这里有一些金额计算逻辑
return order.getAmount() * 0.9; // 打九折的示例
}
// 创建订单
public Order createOrder(String userId, double originalAmount) {
Order order = new Order();
order.setOrderId("ORD" + System.currentTimeMillis());
order.setUserId(userId);
order.setAmount(originalAmount);
return order;
}
}
// 订单通知类，只负责订单通知相关功能
class OrderNotifier {
public void sendOrderNotification(Order order) {
// 发送通知的逻辑，比如发短信、发邮件
System.out.println("订单" + order.getOrderId() + "已创建，用户" + order.getUserId() + "请注意查收");
}
}
// 订单持久化类，只负责订单数据的存储
class OrderRepository {
public void saveOrder(Order order) {
// 保存到数据库的逻辑
System.out.println("订单" + order.getOrderId() + "已保存到数据库");
}
}
// 原来的OrderService可以改为协调类，只负责调用各个职责类的功能，本身不承担具体业务逻辑
class OrderService {
private OrderManager orderManager;
private OrderNotifier orderNotifier;
private OrderRepository orderRepository;
// 构造方法注入依赖
public OrderService(OrderManager orderManager, OrderNotifier orderNotifier, OrderRepository orderRepository) {
this.orderManager = orderManager;
this.orderNotifier = orderNotifier;
this.orderRepository = orderRepository;
}
public void processOrder(String userId, double originalAmount) {
// 创建订单
Order order = orderManager.createOrder(userId, originalAmount);
// 计算金额
double finalAmount = orderManager.calculateAmount(order);
order.setAmount(finalAmount);
// 保存订单
orderRepository.saveOrder(order);
// 发送通知
orderNotifier.sendOrderNotification(order);
}
}
拆分时的注意事项
在拆分类功能的时候，不需要过度追求拆分到极致，要结合实际的业务场景判断。如果一个类的两个职责总是在一起变化，比如用户的基本信息和用户的展示格式，两者修改的频率一致，那么暂时放在同一个类里也是合理的。判断的标准是看这个类是否有多个引起它变化的原因，而不是看它有多少个方法。
另外，单一职责原则不仅适用于类，也适用于方法和模块。方法也应该只做一件事，模块也应该只负责某一领域的功能，这样才能从整体上提升代码的质量。
单一职责原则的核心不是减少类的数量，而是让每个类的职责边界清晰，降低单个类的复杂度，让代码更容易理解和维护。