单一职责原则（Single Responsibility Principle，简称是SRP）是面向对象设计五个基本原则（SOLID）之一，它规定一个类应该只有一个发生变化的原因。所谓职责是指类变化的原因，如果一个类有多于一个的动机被改变，那么这个类就具有多于一个的职责，而单一职责原则就是指一个类或者模块应该有且只有一个改变的原因。

程序员必知！单一职责原则的实战应用与案例分析 - 程序员古德

定义

单一职责原则的核心思想是，一个类只做一件事情，并且将这件事情做好。

如果一个类承担了太多的职责，那么当其中一个职责发生变化时，可能会影响到其他职责的实现，从而增加系统的复杂性和维护成本。因此，通过将类的职责分解为多个独立的类，可以降低类的复杂度，提高代码的可读性和可维护性。

在实际应用中，单一职责原则通常与接口隔离原则一起使用，通过将大接口拆分为多个小接口，每个接口只包含一个职责，从而实现接口的隔离。同时，单一职责原则也可以与其他设计模式结合使用，如工厂模式、策略模式等，以实现更加灵活和可扩展的设计。

代码案例

假设我们有一个电商平台，其中有一个功能是处理用户的订单。我们可以设计一个订单类（Order）来表示订单的数据和行为。

首先，我们来看一下没有遵循单一职责原则的设计方式。在这种设计中，我们可能会在订单类中处理订单的创建、支付、发货和完成等所有逻辑。

代码如下所示：

// 没有遵循单一职责原则的订单类

/**
 * @版权 Copyright by 程序员古德 <br>
 * @创建人 程序员古德 <br>
 * @创建时间 2023/12/14 16:37 <br>
 */
public class Order {
    private String orderId;
    private String userId;
    private String productId;
    private double amount;
    private OrderStatus status;

    public void createOrder(String userId, String productId, double amount) {
        // 创建订单的逻辑  
    }

    public void payOrder() {
        // 支付订单的逻辑  
    }

    public void shipOrder() {
        // 发货的逻辑  
    }

    public void completeOrder() {
        // 完成订单的逻辑  
    }
}

这种设计方式将订单的不同职责（创建、支付、发货和完成）都放在了同一个类中，导致类的职责过多，违反了单一职责原则。

现在，我们来看一下如何使用单一职责原则来改进这个设计。

我们可以将订单的创建、支付、发货和完成等逻辑分离到不同的类中，每个类只负责一个具体的职责。代码如下所示：

/**
 * @版权 Copyright by 程序员古德 <br>
 * @创建人 程序员古德 <br>
 * @创建时间 2023/12/14 16:37 <br>
 */

// 订单接口
public interface Order {
    void create();

    void pay();

    void ship();

    void complete();
}

// 订单创建类
public class OrderCreator implements Order {
    @Override
    public void create() {
// 创建订单的逻辑
    }
}

// 订单支付类
public class OrderPayer implements Order {
    @Override
    public void pay() {
// 支付订单的逻辑
    }
}

// 订单发货类
public class OrderShipper implements Order {
    @Override
    public void ship() {
// 发货的逻辑
    }
}

// 订单完成类
public class OrderCompleter implements Order {
    @Override
    public void complete() {
// 完成订单的逻辑
    }
}

在改进后的设计中，我们定义了一个订单接口（Order），其中声明了订单的创建、支付、发货和完成等方法。然后，我们分别创建了订单创建类（OrderCreator）、订单支付类（OrderPayer）、订单发货类（OrderShipper）和订单完成类（OrderCompleter），每个类只负责实现相应的方法逻辑。这样，每个类都有一个明确的职责，并且只关注于自己负责的功能。

核心总结

优点

降低类的复杂度，一个类只负责一项职责，其逻辑肯定要比负责多项职责简单得多。
提高类的可读性，复杂性降低，自然其可读性会提高。
提高系统的可维护性，可读性提高，那自然更容易维护了。
变更引起的风险降低，变更是必不可少的，如果一个类的职责过多，一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计，当变化发生时，设计会遭受到破坏。而单一职责原则提出了分开的设计理念，一个类受到的影响最小。

缺点

过度遵循单一职责原则可能会导致系统中的类过多，增加系统的复杂性。每个类只负责一个职责，这意味着为了实现一个功能，可能需要创建多个类。这样会增加类的数量和相互之间的依赖关系，使得系统变得更加复杂。
单一职责原则可能会增加代码的耦合性。虽然每个类的职责单一，但它们之间可能需要相互协作才能完成一项任务。这种相互依赖和协作可能会导致代码之间的耦合性增加，降低代码的可维护性和可扩展性。
过度拆分职责可能会导致代码的阅读和理解难度增加。当系统中的类过多，并且每个类的职责非常细化时，对于其他开发人员来说，理解整个系统的结构和各个类之间的关系可能变得更加困难。这可能会增加开发人员的学习成本和维护成本。

建议

适度应用此原则，避免过度拆分。确保拆分后的类职责明确、接口清晰。与其他设计原则结合使用，如接口隔离和依赖倒置，效果更佳。在大型复杂系统中，应用单一职责原则能提高代码质量和可维护性，但需权衡考虑，避免过度设计。设计应以满足实际需求和便于维护为目标。