软件设计原则之单一职责原则

软件设计原则之单一职责原则

引用

CSDN

1.

https://blog.csdn.net/hpx666/article/details/141498982

单一职责原则（SRP）是面向对象设计中的一个重要原则，其核心思想是：一个类应该仅有一个引起它变化的原因。换句话说，一个类应该负责一组相对独立且内聚的职责。

单一职责原则

单一职责原则（Single Responsibility Principle，简称SRP）是面向对象设计中的一个重要原则，其核心思想是：一个类应该仅有一个引起它变化的原因。换句话说，一个类应该负责一组相对独立且内聚的职责。当这个类需要承担更多的职责时，就应该考虑将其拆分为多个类，每个类负责一个单一的职责。

单一职责原则的主要特点

• 清晰性：遵循单一职责原则可以让代码结构更加清晰，每个类或模块只负责完成一项任务，使得代码更容易理解和维护。
• 低耦合：当一个类承担的职责过多时，它与其他类的交互就会变得更加复杂，从而增加了系统的耦合度。遵循单一职责原则，可以使得类与类之间的依赖关系更加清晰，降低耦合度。
• 高内聚：遵循单一职责原则的类通常具有较高的内聚性，即类内的元素之间联系紧密，共同为完成一个职责而努力。
• 可维护性：当系统需要修改或扩展时，如果类的职责单一，那么修改的影响范围就会相对较小，从而更容易维护。
• 可读性：类的职责明确，使得代码更加易于理解和阅读。其他开发者在查看代码时，可以更快地理解类的功能和作用。
• 灵活性：由于类的职责单一，因此可以更容易地对其进行重构或替换，以适应新的需求或技术变化。

如何应用单一职责原则

• 识别职责：首先，需要仔细分析类的职责，明确它应该做什么。这通常需要对系统的需求有深入的理解。
• 划分职责：如果发现一个类承担了多个职责，那么应该考虑将这些职责划分到不同的类中。每个类只负责一个职责，并且这个职责应该是相对独立且内聚的。
• 重构代码：根据职责的划分，对代码进行重构。将原有的类拆分为多个类，每个类只包含与其职责相关的属性和方法。
• 持续审查：随着系统的不断发展和变化，类的职责也可能会发生变化。因此，需要持续审查类的职责，确保它们仍然符合单一职责原则。

应用范围

接口、类、方法。SRP应用到方法中，每个方法的职责明确清晰。接口一定要做到单一职责，类的的设计尽量做到单一职责。

• 类设计：最直接的应用就是在类的设计上。一个类应该只负责一组相对独立的功能或行为。如果一个类承担的职责过多，就应该考虑将其拆分成多个类，每个类负责一个具体的职责。
• 接口设计：接口也应该遵循单一职责原则。一个接口应该只定义一组相关的方法，这些方法应该属于同一职责范畴。如果接口中的方法职责差异较大，应该考虑将其拆分成多个接口。
• 模块设计：在更大的层面上，单一职责原则也适用于模块设计。一个模块应该只负责一组相关的功能，避免模块之间职责的重叠和混淆。
• 服务设计：在微服务架构中，单一职责原则同样重要。每个微服务应该只负责一个独立的业务功能或领域，确保服务的内聚性和独立性。
• 方法设计：虽然单一职责原则主要针对类和接口，但方法的设计也应该尽量遵循这一原则。一个方法应该只完成一个明确的任务，避免在方法内部执行多个不相关的操作。
• 数据库设计：在数据库设计中，单一职责原则也具有一定的指导意义。例如，表的设计应该遵循单一职责原则，一个表应该只存储与某一业务实体相关的数据，避免表中包含多个业务实体的混合数据。
• 组件设计：在组件化开发中，每个组件也应该只负责一个具体的职责。组件之间应该通过清晰的接口进行交互，避免组件内部职责的混乱和交叉。

Demo

用户信息

假设我们有一个User类，它同时负责用户信息的存储和用户登录验证。这明显违反了单一职责原则，因为存储信息和登录验证是两个相对独立的职责。

// 存储用户信息
public class UserInfo {
    private String username;
    private String password;

    // 存储用户信息
    public void saveUserInfo() {
        // 实现存储逻辑
    }
}

// 用户登录验证
public class UserAuthenticator {
    private UserInfo userInfo;

    public UserAuthenticator(UserInfo userInfo) {
        this.userInfo = userInfo;
    }

    // 用户登录验证
    public boolean validateLogin(String inputUsername, String inputPassword) {
        return userInfo.getUsername().equals(inputUsername) && userInfo.getPassword().equals(inputPassword);
    }
}

日志记录

class FileLogger {
    public void log(String message) {
        // 将日志写入文件
    }
}

class DatabaseLogger {
    public void log(String message) {
        // 将日志存入数据库
    }
}

class LogManager {
    private FileLogger fileLogger;
    private DatabaseLogger databaseLogger;

    public LogManager(FileLogger fileLogger, DatabaseLogger databaseLogger) {
        this.fileLogger = fileLogger;
        this.databaseLogger = databaseLogger;
    }

    public void logToFile(String message) {
        fileLogger.log(message);
    }

    public void logToDatabase(String message) {
        databaseLogger.log(message);
    }
}

通过这样的拆分，我们使得每个类的职责更加明确，也更容易进行维护和扩展。虽然单一职责原则很重要，但也要注意避免过度设计。过度遵循单一职责原则可能会导致系统中的类过多、依赖关系复杂，反而增加系统的复杂性和维护成本。因此，在应用单一职责原则时，需要权衡利弊，确保设计的合理性和可行性。