3.3　单一职责原则

3.3.1　单一职责原则的定义

单一职责原则（Simple Responsibility Principle，SRP）指不要存在一个以上导致类变更的原因。假设有一个Class负责两个职责，一旦发生需求变更，修改其中一个职责的逻辑代码，有可能会导致另一个职责的功能发生故障。这样一来，这个Class就存在两个导致类变更的原因。如何解决这个问题呢？我们就要分别用两个Class来实现两个职责，进行解耦。后期需求变更维护互不影响。这样的设计，可以降低类的复杂度，提高类的可读性，提高系统的可维护性，降低变更引起的风险。总体来说就是一个Class、Interface、Method只负责一项职责。

3.3.2　使用单一职责原则解决实际问题

我们来看代码实例，还是用课程举例，我们的课程有直播课和录播课。直播课不能快进和快退，录播课可以任意地反复观看，功能职责不一样。首先创建一个Course类。

然后看客户端代码，无论是直播课还是录播课，都调用study（）方法的逻辑。

从上面代码来看，Course类承担了两种处理逻辑。假如，现在对课程进行加密，那么直播课和录播课的加密逻辑是不一样的，必须修改代码。而修改代码逻辑势必会相互影响，容易带来不可控的风险。我们对职责进行分离解耦，分别创建两个类LiveCourse和ReplayCourse。

LiveCourse类的代码如下。

ReplayCourse类的代码如下。

客户端代码如下，将直播课的处理逻辑调用LiveCourse类，录播课的处理逻辑调用ReplayCourse类。

当业务继续发展时，要对课程做权限。没有付费的学员可以获得课程的基本信息，已经付费的学员可以获得视频流，即学习权限。那么对于控制课程层面，至少有两个职责。我们可以把展示职责和管理职责分离开，都实现同一个抽象依赖。设计一个顶层接口，创建ICourse接口。

可以把这个接口拆成两个接口，创建一个接口ICourseInfo和ICourseManager。

ICourseInfo接口的代码如下。

ICourseManager接口的代码如下。

来看一下类图，如下图所示。

下面来看方法层面的单一职责设计。有时候，为了偷懒，通常会把一个方法写成下面这样。

还可能写成这样。

显然，上面两种写法的modifyUserInfo（）方法都承担了多个职责，既可以修改userName，也可以修改address，甚至更多，明显不符合单一职责原则。那么我们做如下修改，把这个方法拆成两个。

代码在修改之后，开发起来简单，维护起来也容易。在实际项目中，代码会存在依赖、组合、聚合关系，在项目开发过程中还受到项目的规模、周期、技术人员水平、对进度把控的影响，导致很多类都不能满足单一职责原则。但是，我们在编写代码的过程中，尽可能地让接口和方法保持单一职责，对项目后期的维护是有很大帮助的。