设计模式六大原则(一)--单一职责原则

设计模式的六大原则之一是单一职责原则（Single Responsibility Principle，简称 SRP）。这是面向对象设计中最基本的原则之一，也是 SOLID 原则中的“S”。以下是关于单一职责原则的一些要点：
单一职责原则定义
单一职责原则指出，一个类应该有且仅有一个引起它变化的原因。换句话说，一个类应该专注于实现一个特定的功能或职责，并且这个职责应该是独立的，与其他职责无关。
单一职责原则的核心思想
•  减少变化的影响：如果一个类承担多个职责，那么当其中一个职责发生变化时，可能会对其他职责产生负面影响。单一职责原则通过将职责分离到不同的类中来减少这种影响。
•  提高代码的可维护性：单一职责原则有助于降低类的复杂度，使得代码更容易理解和维护。
•  降低耦合性：遵循单一职责原则可以减少类之间的相互依赖，提高系统的灵活性。
应用范围
单一职责原则适用于类、接口、方法等。通常情况下，接口和方法应该保持职责单一，而对于类，是否需要遵循单一职责原则取决于具体的业务需求和设计决策。
实例说明
假设有一个名为 OrderManager 的类，它负责处理订单的创建和支付：

public class OrderManager {
    public void createOrder(String product, int quantity) {
        // 创建订单的逻辑
    }

    public void processPayment(double amount) {
        // 支付处理的逻辑
    }
}

这里 OrderManager 类包含了两个职责：创建订单和处理支付。如果将来需要对支付方式进行调整，这可能会间接影响到订单创建的部分。为了避免这种情况，可以将这两个职责分离到不同的类中：

public class OrderCreator {
    public void createOrder(String product, int quantity) {
        // 创建订单的逻辑
    }
}

public class PaymentProcessor {
    public void processPayment(double amount) {
        // 支付处理的逻辑
    }
}

这样，即使支付逻辑发生变化，也不会影响到订单创建的逻辑。
注意事项
•  职责的界定：确定一个类的职责并不是一件简单的事情，需要根据实际情况来决定。
•  过度拆分：将类拆分得太细可能导致代码耦合性增加，反而影响可维护性。
•  设计的平衡：单一职责原则需要与其他设计原则（如开闭原则、里氏替换原则等）结合起来考虑，寻找最佳的设计方案。
遵循单一职责原则可以帮助开发人员编写出更易于维护和扩展的代码。然而，在实际应用中，还需要根据项目的具体情况灵活应用这些原则。