单一职责原则（SRP）详解

Zephyrzh

已于 2025-04-11 16:40:18 修改

阅读量945

点赞数 27

分类专栏：设计模式文章标签：单一职责原则设计模式

于 2025-04-11 15:45:41 首次发布

本文链接：https://blog.youkuaiyun.com/u013713832/article/details/147144326

版权

设计模式专栏收录该内容

2 篇文章

订阅专栏

核心定义

1. 职责与“变化原因”的关系

2. 典型案例分析

场景：设计一个用户管理系统，包含以下功能：

核心定义

单一职责原则（Single Responsibility Principle, SRP） 要求一个类仅有一个引起它变化的原因。换句话说，每个类应该专注于单一功能或业务逻辑，避免将多个职责耦合在一起。

1. 职责与“变化原因”的关系

首先，我需要弄清楚什么是“职责”和“引起变化的原因”。这里的“职责”指的是类应该做的事情，而“引起变化的原因”则是指当需求变化时，导致类需要修改的原因。假设有一个类，它负责处理用户数据的读取和写入。根据SRP，这个类应该只做一件事情，要么读，要么写，而不是同时负责两者。如果这个类同时处理读和写，那么当读取逻辑需要修改时，或者写入逻辑需要调整时，都需要修改同一个类，这就可能引入错误，或者让类的复杂度增加。因此，应该将读和写分开成两个类，各自负责自己的部分。

职责（Responsibility）：指类承担的功能或任务（例如：数据存储、日志记录、格式转换等）。
变化原因（Reason to Change）：当需求变动时，导致类需要修改的触发点。

关键理解：
如果一个类承担多个职责，那么每个职责的修改都可能触发类的变更。通过分离职责，可以降低修改代码的风险和复杂度。

2. 典型案例分析

场景：设计一个用户管理系统，包含以下功能：

用户信息管理（增删改查）
用户数据持久化（保存到数据库）
用户操作日志记录

错误设计：违反 SRP

class UserService {
    // 职责1：用户管理
    public void addUser(User user) {
        // 业务逻辑...
        saveToDatabase(user);  // 职责2：数据持久化
        log("用户添加：" + user.getName());  // 职责3：日志记录
    }

    private void saveToDatabase(User user) { /* 数据库操作 */ }
    private void log(String message) { /* 日志写入 */ }
}

问题：

修改数据库存储方式（如切换为 NoSQL）需要修改 UserService
调整日志格式或存储位置（如改为云日志）也需要修改 UserService
一个类承担了三个职责，任何改动都可能影响其他功能。

正确设计：遵循 SRP

将存储和日志抽象为接口，交给具体实现完成，实现解耦，当需要修改数据库存储方式（切换为NoSQL）只需要调整接口实现类即可，用户管理类职责不变的情况下实现其他功能调整。

// 职责1：用户管理（核心业务）
class UserManager {
    private UserRepository repository;  // 依赖抽象接口
    private Logger logger;

    public UserManager(UserRepository repository, Logger logger) {
        this.repository = repository;
        this.logger = logger;
    }

    public void addUser(User user) {
        repository.save(user);  // 委托数据持久化
        logger.log("用户添加：" + user.getName());  // 委托日志记录
    }
}

// 职责2：数据持久化（接口+实现）
interface UserRepository {
    void save(User user);
}
class DatabaseUserRepository implements UserRepository {
    @Override
    public void save(User user) { /* 数据库操作 */ }
}

// 职责3：日志记录（接口+实现）
interface Logger {
    void log(String message);
}
class FileLogger implements Logger {
    @Override
    public void log(String message) { /* 写入文件 */ }
}

优势：

用户管理、数据存储、日志记录完全解耦
修改存储方式只需替换 UserRepository 实现类
调整日志逻辑只需替换 Logger 实现类
每个类仅因自身职责的变化而修改。

3. 如何判断职责是否单一？

有时候职责的划分不那么明显。比如，一个图形类，可能负责绘制图形和计算面积。这两者是否属于同一个职责呢？绘制图形和计算面积都跟图形本身相关，可能属于同一职责。但如果绘制图形的方式和计算面积的算法会因为不同的需求而变化，那么是否需要分开？比如，如果不同的输出设备需要不同的绘制方式，而面积计算也可能有不同的方法，这时候可能需要分开。因此职责的划分不仅仅是功能上的分离，而是基于变化的可能性。如果一个类因为多个不同的原因需要修改，那么这些原因对应的职责就应该被分离。例如，用户认证类，如果它同时处理密码加密和用户会话管理，那么当加密算法改变或者会话管理逻辑改变时，都需要修改同一个类，这时候应该分开。

方法1：描述类的作用

如果类的描述包含“并且”或“或者”（例如：“管理用户并且记录日志”），则可能违反 SRP。
正确示例：UserManager（用户管理）、UserRepository（数据存储）、Logger（日志记录）。

方法2：分析修改场景

触发修改的场景是否独立？
示例：若修改密码加密算法不影响用户信息验证逻辑，则两者应拆分。

4. SRP 的实践技巧

(1) 通过依赖注入解耦

// 高层类通过接口依赖低层实现
class OrderProcessor {
    private PaymentGateway paymentGateway;  // 支付接口
    private InventoryService inventoryService;  // 库存接口

    // 通过构造函数注入具体实现
    public OrderProcessor(PaymentGateway gateway, InventoryService inventory) {
        this.paymentGateway = gateway;
        this.inventoryService = inventory;
    }
}

(2) 拆分“上帝类”

常见反模式：一个类包含数百行代码，处理多种任务（如 Utils 类）。

改进方案：

// 错误
class CommonUtils {
    static String formatDate(Date date) { /* ... */ }
    static void sendEmail(String to, String content) { /* ... */ }
    static boolean validatePassword(String password) { /* ... */ }
}

// 正确
class DateFormatter { /* 日期格式化 */ }
class EmailService { /* 邮件发送 */ }
class PasswordValidator { /* 密码校验 */ }

(3) 识别聚合根

在领域驱动设计（DDD）中，聚合根应管理核心业务逻辑，其他职责（如持久化、通知）交给外部服务。

5. SRP 的边界与权衡

有时候过度拆分职责可能导致类数量激增，增加系统的复杂度。因此，在应用SRP时需要权衡，确保职责的划分合理，既不过于粗放也不过于细分。例如，一个简单的数据模型类可能只需要包含属性和基本的验证，而不需要将每个验证规则都拆分成单独的类，除非这些验证规则确实会因不同原因而变化。

何时不必严格拆分？

简单工具类：如 MathUtils 包含多个数学计算方法，若方法间无依赖且稳定，可保持统一。
性能敏感场景：过度拆分可能导致对象创建开销，需权衡可维护性与性能。

典型误用案例

将用户管理中的每个操作拆分为接口

// 错误：为每个方法单独拆分接口
interface UserSaver { void save(User user); }
interface UserDeleter { void delete(User user); }
interface UserUpdater { void update(User user); }

// 正确：用户仓库统一管理持久化操作
interface UserRepository {
    void save(User user);
    void delete(User user);
    void update(User user);
}

6. SRP 的收益

维度	说明
可维护性	修改一个功能不影响其他模块，降低回归测试成本
可读性	每个类职责明确，代码更易理解
可测试性	单一职责类更容易编写单元测试（如单独测试日志模块或数据库模块）
复用性	独立职责的模块可被多个系统复用（如日志模块可独立抽取为公共组件）