设计模式六大原则之：单一职责原则

1. 单一职责简介

设计模式中的单一职责原则（‌Single Responsibility Principle, SRP）‌是面向对象设计中的一个基本原则，‌它强调一个类应该仅有一个引起它变化的原因。‌换句话说，‌一个类应该负责一组相对独立且紧密相关的职责，‌并且当这个类需要变更时，‌变更的原因应该只有一个。‌

“单一职责原则”是开发生命周期中一个非常重要的原则，它旨在指导开发者如何组织代码，使得每个模块、类或函数都只负责一项特定的任务或职责。

2. 单一职责核心思想

SRP的核心思想（基本理念）是，一个对象应该只关注一件事，即它的责任仅限于执行一个明确的业务功能。这个原则由罗伯特·C·马丁(Robert C. Martin)在其著作《Clean Code》中首次明确提出，其目的是提高代码的可读性、可维护性和模块间的独立性。当一个类承担了过多的功能，例如处理输入、计算结果、输出结果等混合在一起时，会变得难以理解和修改。这样的设计不利于团队协作，也容易引发错误。

其主要特性如下：

2.1 职责分离

将不同的职责分离到不同的类或模块中，‌有助于降低系统的复杂性，‌提高系统的可维护性。‌

2.2 高内聚低耦合

遵循单一职责原则的类通常具有较高的内聚性（‌即类的内部元素之间联系紧密）‌和较低的耦合性（‌即类与类之间的依赖关系简单）‌。‌

2.3 易于扩展

当系统需要增加新功能时，‌可以更容易地通过添加新的类来实现，‌而不是修改现有的类。‌

3. 单一职责应用场景

遵循单一职责原则有助于创建更具弹性的系统，它的应用场景主要体现在如下几个方面：

3.1 职责识别

首先，‌需要仔细分析类的职责，‌确保每个类都只有一个明确的职责。‌如果发现一个类承担了多个职责，‌那么应该考虑将这些职责分离到不同的类中。‌

3.2 重构代码

在识别出类的多个职责后，‌可以通过重构代码来将这些职责分离。‌这通常涉及到将类拆分成多个更小的类，‌每个类都负责一个单一的职责。‌

3.3 接口隔离

单一职责原则也适用于接口设计。‌一个接口应该只包含一组紧密相关的方法，‌而不应该包含与接口主要目的无关的方法。‌这有助于保持接口的简洁和清晰。‌

4. 单一职责使用步骤

清晰定义类边界：确定一个类应该包含哪些行为，以及应该对外提供什么样的接口。理想情况下，这个接口应该是最小化的，只包含完成其职责所需的操作。
将复杂功能拆分：如果某个功能过于庞大，考虑将其分解为几个更小、更专注的函数或类。这可以提高代码的复用性，并使其更容易测试。
避免过度继承：过多的继承可能导致类变得臃肿，难以理解。除非有明确的继承关系和共享行为，否则通常建议选择组合而非继承。
尽量使用接口和抽象类：它们可以帮助封装职责并提供统一的行为规范，让具体的实现细节隐藏起来。
遵循高内聚低耦合原则：一个类内部应该高度关联，对外则尽可能地松散耦合。这样可以确保当其中一个部分改变时，不会对其他部分造成大的影响。
定期审查代码：定期评估类的职责是否仍然清晰，是否有需要重构的地方。如果发现某类职责范围过大，可能是时候拆分成两个或更多的类了。

5. 单一职责代码示例

现在假设我们有一个类Vehicle，它负责汽车的行驶和停车功能。如果汽车行驶逻辑发生变化，或者停车逻辑发生变化，那么Vehicle类就会受到影响，这违反了单一职责原则。解决这个问题的方法是将行驶和停车功能分离到不同的类中，例如DriveController和ParkingSystem。

5.1 违反单一职责的代码设计`Vehicle`

// 违反单一职责的设计
class Vehicle
{public void drive() {// 实现行驶逻辑}public void park() {// 实现停车逻辑}
}

5.2 用单一职责思想拆分`Vehicle`

// 行驶控制器
class DriveController {public void drive() {// 实现行驶逻辑}
}// 停车系统
class ParkingSystem {public void park() {// 实现停车逻辑}
}// 使用示例
public class SingleResponsibilityPrincipleExample {public static void main(String[] args) {DriveController driveController = new DriveController();driveController.drive();ParkingSystem parkingSystem = new ParkingSystem();parkingSystem.park();}
}

在这个例子中，DriveController类只负责汽车的行驶功能，而ParkingSystem类只负责汽车的停车功能。这样一来，如果行驶逻辑或停车逻辑发生变化，只需修改对应的类即可，不会影响其他部分的代码。这就是单一职责原则的应用。

6. 总结

综上所述，单一职责原则(Single Responsibility Principle, SRP) 是面向对象设计中的一个基本原则，它提倡一个类或者一个模块应当只有一个引起它变化的原因。简单来说，就是每个类应负责一个明确的任务，并且这个任务只有一个原因导致其改变。以下是这个原则的一些关键点：

定义清晰: 类应有明确且具体的职责，使其能完成单一目标，比如管理数据库连接，或者处理用户请求。
高内聚: 类内的所有方法应该密切相关的服务于同一项功能，彼此之间相互独立，互不影响。
低耦合: 类之间的依赖程度尽量低，这样当一个类需要更改时，不会波及到其他无关的类，提高了代码的稳定性。
避免过多功能: 避免在一个类中包含过多的特性或行为，每个类都应该有自己的专业领域，减少复杂性。
可扩展性: 当需求变化时，由于职责明确，只需修改负责那部分职责的部分即可，不需要牵涉全局。
易于测试: 因为职责集中，单个类的单元测试相对简单，有利于测试驱动开发(TDD)。
利于重构: 单一职责有助于识别并孤立出可以独立调整的代码块，使得重构变得更简单。

遵循单一职责原则有助于编写出易于理解、稳定和可维护的代码。然而，也要注意过犹不及，适度的职责划分才能保持设计的平衡。

设计模式六大原则之：单一职责原则

1. 单一职责简介