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

单一职责原则（Single Responsibility Principle，SRP）是面向对象设计中的一个原则，它要求一个类或模块应该有且只有一个引起它变化的原因。

单一职责原则主要解决的问题是类的职责过于复杂，即一个类承担了过多的责任。当一个类具有多个职责时，任何一个职责的变化都可能影响到其他职责，导致代码的脆弱性和可维护性下降。

需要使用单一职责原则的时候，通常有以下情况：

1. 当一个类承担了多个不同的职责时，可以考虑将这些职责分离到不同的类中，以遵循单一职责原则。
2. 当一个类的职责变得过于庞大复杂时，容易引发代码的混乱和难以维护，可以使用单一职责原则来重新设计和拆分类的职责。

假设你有一个笔记本电脑，它有多个功能：浏览器浏览网页、文本编辑器写作、音乐播放器播放音乐等。如果你把所有这些功能都放在一个类中，那么这个类就承担了太多的职责，一旦其中一个功能需要修改或添加新功能，就会影响到其他功能的稳定性。

相反，如果你将浏览器、文本编辑器和音乐播放器分别作为独立的类来实现，每个类只负责自己的功能，那么当你需要修改或扩展其中一个功能时，不会对其他功能产生影响，代码也更加清晰和易于维护。

单一职责原则的优点包括：

1. 提高代码的可读性和可维护性，因为每个类都只关注自己的单一职责，代码逻辑更加清晰。
2. 减少类之间的耦合性，一个类的变化不会影响到其他类。

单一职责原则也有一些缺点：

1. 类的数量可能会增加，特别是在职责非常细粒度的情况下，可能会导致类的爆炸性增长。
2. 过度拆分职责可能会导致系统中存在大量的小类，增加了代码的复杂性和维护的困难度。

适合使用单一职责原则的场景包括：

1. 当一个类承担了多个不同的职责时，可以考虑将这些职责分离到不同的类中，以遵循单一职责原则。
2. 当一个类的职责变得过于庞大复杂时，容易引发代码的混乱和难以维护，可以使用单一职责原则来重新设计和拆分类的职责。

通过一个简单的代码示例来说明单一职责原则的使用：

// 不符合单一职责原则的类
class Employee {
    public void performTaskA() {
        // 执行任务A的逻辑
    }

    public void performTaskB() {
        // 执行任务B的逻辑
    }

    public void calculateSalary() {
        // 计算工资的逻辑
    }
}

// 符合单一职责原则的类
class Employee {
    public void performTaskA() {
        // 执行任务A的逻辑
    }

    public void performTaskB() {
        // 执行任务B的逻辑
    }
}

class PayrollSystem {
    public voidcalculateSalary(Employee employee) {
        // 计算工资的逻辑
    }
}

在上面的示例中，原始的Employee类违反了单一职责原则，因为它既负责执行任务A和任务B，又负责计算工资。

为了符合单一职责原则，我们将任务A和任务B的逻辑分离到Employee类中，而将计算工资的逻辑放在一个新的PayrollSystem类中。

这样一来，当需要修改任务A或任务B的逻辑时，不会影响到计算工资的功能，也使得代码更加清晰和易于维护。

这个示例展示了单一职责原则如何帮助我们将功能职责分离，提高代码的可读性、可维护性和扩展性。