02.单一职责原则详解

目录介绍

01.问题思考分析
02.单一职责原则介绍
03.如何理解单一指责
04.用例子理解单一职责
05.为何遵守单一原则
06.方法层面单一职责
07.接口层面单一职责
08.类层面单一职责
09.单一职责判断模糊
10.单一职责判断原则
11.最后总结一下
12.更多内容推荐

01.问题思考分析

如何理解类的单一指责，单一指责中这个单一是如何评判的？
懂了，但是会用么，或者实际开发中有哪些运用，能否举例说明单一职责优势？
单一指责是否设计越单一，越好呢？说出你的缘由和论证的思路想法？
单一职责原则，除了应用到类的设计上，还能延伸到哪些其他设计方面吗？

02.单一职责原则介绍

单一责任原则（Single Responsibility Principle，SRP）是面向对象设计中的一条重要原则。

这个原则的英文描述是这样的：A class or module should have a single responsibility。

如果我们把它翻译成中文，那就是：一个类或者模块只负责完成一个职责（或者功能）。

也就是说，一个模块或类应该只负责一个特定的职责或功能，通过将功能分解到不同的模块或类中，可以使系统更加灵活、可维护和可扩展。

从字面上理解，不难。你一看就感觉懂了，一看就感觉掌握了，但真的用到项目中的时候，你会发现，“看懂”和“会用”是两回事，而“用好”更是难上加难。

从工作经历来看，很多同事因为对这些原则理解得不够透彻，导致在使用的时候过于教条主义，拿原则当真理，生搬硬套，适得其反。

03.如何理解单一指责

单一原则描述的对象包含两个，一个是类（class），一个是模块（module）。

关于这两个概念，在专栏中，有两种理解方式。一种理解是：把模块看作比类更加抽象的概念，类也可以看作模块。另一种理解是：把模块看作比类更加粗粒度的代码块，模块中包含多个类，多个类组成一个模块。

不管哪种理解方式，单一职责原则在应用到这两个描述对象的时候，道理都是相通的。为了方便你理解，接下来我只从“类”设计的角度，来讲解如何应用这个设计原则。对于“模块”来说，你可以自行引申。

04.用例子理解单一职责

单一职责原则的定义描述非常简单，也不难理解。一个类只负责完成一个职责或者功能。也就是说，不要设计大而全的类，要设计粒度小、功能单一的类。换个角度来讲就是，一个类包含了两个或者两个以上业务不相干的功能，那我们就说它职责不够单一，应该将它拆分成多个功能更加单一、粒度更细的类。

举一个例子来解释一下。比如，一个类里既包含订单的一些操作，又包含用户的一些操作。而订单和用户是两个独立的业务领域模型，我们将两个不相干的功能放到同一个类中，那就违反了单一职责原则。

为了满足单一职责原则，我们需要将这个类拆分成两个粒度更细、功能更加单一的两个类：订单类和用户类。

05.为何遵守单一原则

通常，我们做事情都要知道为什么要这么做，才回去做。做的也有底气，那么为什么我们要使用单一职责原则呢?

提高类的可维护性和可读写性。一个类的职责少了，复杂度降低了，代码就少了，可读性也就好了，可维护性自然就高了。
提高系统的可维护性。系统是由类组成的，每个类的可维护性高，相对来讲整个系统的可维护性就高。
降低变更的风险。一个类的职责越多，变更的可能性就越大，变更带来的风险也就越大

06.方法层面单一职责

现在有一个场景，需要修改用户的用户名和密码，就针对这个功能我们可以有多种实现。

先看一下第一种实现方式：

public enum OperateEnum {
    UPDATE_USERNAME，
    UPDATE_PASSWORD;
}

public interface UserOperate {
    void updateUserInfo(OperateEnum type，UserInfo userInfo);
}

public class UserOperateImpl implements UserOperate{
    @Override
    public void updateUserInfo(OperateEnum type，UserInfo userInfo) {
        if (type == OperateEnum。UPDATE_PASSWORD) {
            // 修改密码
        } else if(type == OperateEnum。UPDATE_USERNAME) {
            // 修改用户名
        }
    }
}

然后看一下第二种实现方式：

public interface UserOperate {

    void updateUserName(UserInfo userInfo);

    void updateUserPassword(UserInfo userInfo);
}

public class UserOperateImpl implements UserOperate {
    @Override
    public void updateUserName(UserInfo userInfo) {
        // 修改用户名逻辑
    }

    @Override
    public void updateUserPassword(UserInfo userInfo) {
        // 修改密码逻辑
    }
}

来看看这两种实现的区别:

第一种实现是根据操作类型进行区分，不同类型执行不同的逻辑。把修改用户名和修改密码这两件事耦合在一起了。如果客户端在操作的时候传错了类型，那么就会发生错误。
第二种实现是我们推荐的实现方式。修改用户名和修改密码逻辑分开，各自执行各自的职责，互不干扰，功能清晰明了。

由此可见，第二种设计是符合单一职责原则的。这是在方法层面实现单一职责原则。

07.接口层面单一职责

我们假设一个场景，大家一起做家务，张三扫地，李四买菜。李四买完菜回来还得做饭。这个逻辑怎么实现呢?

先看一下第一种实现方式：

/**
 * 做家务
 */
public interface HouseWork {
    // 扫地
    void sweepFloor();

    // 购物
    void shopping();
}

public class Zhangsan implements HouseWork{
    @Override
    public void sweepFloor() {
        // 扫地
    }

    @Override
    public void shopping() {

    }
}

public class Lisi implements HouseWork{
    @Override
    public void sweepFloor() {

    }

    @Override
    public void shopping() {
        // 购物
    }
}

首先定义了一个做家务的接口，定义两个方法扫地和买菜。张三扫地，就实现扫地接口。李四买菜，就实现买菜接口。然后李四买完菜回来还要做饭，于是就要在接口类中增加一个方法cooking。张三和李四都重写这个方法，但只有李四有具体实现。

这样设计本身就是不合理的。首先: 张三只扫地，但是他需要重写买菜方法，李四不需要扫地，但是李四也要重写扫地方法。第二: 这也不符合开闭原则。增加一种类型做饭，要修改3个类。这样当逻辑很复杂的时候，很容易引起意外错误。

上面这种设计不符合单一职责原则，修改一个地方，影响了其他不需要修改的地方。

然后看一下第二种实现方式：

/**
 * 做家务
 */
public interface Hoursework {

}

public interface Shopping extends Hoursework{
    // 购物
    void shopping();
}

public interface SweepFloor extends Hoursework{
    // 扫地
    void sweepFlooring();
}

public class Zhangsan implements SweepFloor{

    @Override
    public void sweepFlooring() {
        // 张三扫地
    }
}

public class Lisi implements Shopping{
    @Override
    public void shopping() {
        // 李四购物
    }
}

上面做家务不是定义成一个接口，而是将扫地和做家务分开了。张三扫地，那么张三就实现扫地的接口。李四购物，李四就实现购物的接口。后面李四要增加一个功能做饭。那么就新增一个做饭接口，这次只需要李四实现做饭接口就可以了。

public interface Cooking extends Hoursework{ 
    void cooking();
}

public class Lisi implements Shopping, Cooking{
    @Override
    public void shopping() {
        // 李四购物
    }

    @Override
    public void cooking() {
        // 李四做饭
    }
}

如上, 我们看到张三没有实现多余的接口, 李四也没有. 而且当新增功能的时候, 只影响了李四, 并没有影响张三.

这就是符合单一职责原则. 一个类只做一件事. 并且他的修改不会带来其他的变化.

08.类层面单一职责

从类的层面来讲, 没有办法完全按照单一职责原来来拆分. 换种说法, 类的职责可大可小, 不想接口那样可以很明确的按照单一职责原则拆分. 只要符合逻辑有道理即可.

比如, 我们在网站首页可以注册, 登录, 微信登录.注册登录等操作. 我们通常的做法是:

public interface UserOperate {

    void login(UserInfo userInfo);

    void register(UserInfo userInfo);

    void logout(UserInfo userInfo);
}


public class UserOperateImpl implements UserOperate{
    @Override
    public void login(UserInfo userInfo) {
        // 用户登录
    }

    @Override
    public void register(UserInfo userInfo) {
        // 用户注册
    }

    @Override
    public void logout(UserInfo userInfo) {
        // 用户登出
    }
}

那如果按照单一职责原则拆分, 也可以拆分为下面的形式

public interface Register {
    void register();
}

public interface Login {
    void login();
}

public interface Logout {
    void logout();
}


public class RegisterImpl implements Register{

    @Override
    public void register() {

    }
}

public class LoginImpl implements Login{
    @Override
    public void login() {
        // 用户登录
    }
}

public class LogoutImpl implements Logout{

    @Override
    public void logout() {

    }
}

09.单一职责判断模糊

在真实的软件开发中，对于一个类是否职责单一的判定，是很难拿捏的。我举一个更加贴近实际的例子来给你解释一下。

在一个社交产品中，我们用下面的 UserInfo 类来记录用户的信息。你觉得，UserInfo 类的设计是否满足单一职责原则呢？

public class UserInfo {
  private long userId;
  private String username;
  private String email;
  private String telephone;
  private long createTime;
  private long lastLoginTime;
  private String avatarUrl;
  private String provinceOfAddress; // 省
  private String cityOfAddress; // 市
  private String regionOfAddress; // 区 
  private String detailedAddress; // 详细地址
  // 。。。省略其他属性和方法。。。
}

对于这个问题，有两种不同的观点。

一种观点是，UserInfo 类包含的都是跟用户相关的信息，所有的属性和方法都隶属于用户这样一个业务模型，满足单一职责原则；
另一种观点是，地址信息在 UserInfo 类中，所占的比重比较高，可以继续拆分成独立的 UserAddress 类，UserInfo 只保留除 Address 之外的其他信息，拆分之后的两个类的职责更加单一。

哪种观点更对呢？实际上，要从中做出选择，我们不能脱离具体的应用场景。

如果在这个社交产品中，用户的地址信息跟其他信息一样，只是单纯地用来展示，那 UserInfo 现在的设计就是合理的。
如果这个社交产品发展得比较好，之后又在产品中添加了电商的模块，用户的地址信息还会用在电商物流中，那我们最好将地址信息从 UserInfo 中拆分出来，独立成用户物流信息（或者叫地址信息、收货信息等）。

从刚刚这个例子，我们可以总结出，不同的应用场景、不同阶段的需求背景下，对同一个类的职责是否单一的判定，可能都是不一样的。在某种应用场景或者当下的需求背景下，一个类的设计可能已经满足单一职责原则了，但如果换个应用场景或着在未来的某个需求背景下，可能就不满足了，需要继续拆分成粒度更细的类。

有时候一个类的职责是否足够单一，我们并没有一个非常明确的、可以量化的标准，可以说，这是件非常主观、仁者见仁智者见智的事情。

10.单一职责判断原则

可能会说，这个原则如此含糊不清、模棱两可，到底该如何拿捏才好啊？我这里还有一些小技巧，能够很好地帮你，从侧面上判定一个类的职责是否够单一。下面这几条判断原则，比起很主观地去思考类是否职责单一，要更有指导意义、更具有可执行性：

类中的代码行数、函数或属性过多，会影响代码的可读性和可维护性，我们就需要考虑对类进行拆分；
类依赖的其他类过多，或者依赖类的其他类过多，不符合高内聚、低耦合的设计思想，我们就需要考虑对类进行拆分；
私有方法过多，我们就要考虑能否将私有方法独立到新的类中，设置为 public 方法，供更多的类使用，从而提高代码的复用性；
比较难给类起一个合适名字，很难用一个业务名词概括，或者只能用一些笼统的 Manager、Context 之类的词语来命名，这就说明类的职责定义得可能不够清晰；
类中大量的方法都是集中操作类中的某几个属性，比如，在 UserInfo 例子中，如果一半的方法都是在操作 address 信息，那就可以考虑将这几个属性和对应的方法拆分出来。

11.最后总结一下

如何理解单一职责原则（SRP）？

一个类只负责完成一个职责或者功能。不要设计大而全的类，要设计粒度小、功能单一的类。单一职责原则是为了实现代码高内聚、低耦合，提高代码的复用性、可读性、可维护性。

如何判断类的职责是否足够单一？

不同的应用场景、不同阶段的需求背景、不同的业务层面，对同一个类的职责是否单一，可能会有不同的判定结果。实际上，一些侧面的判断指标更具有指导意义和可执行性，比如，出现下面这些情况就有可能说明这类的设计不满足单一职责原则：
类中的代码行数、函数或者属性过多；
类依赖的其他类过多，或者依赖类的其他类过多；
私有方法过多；
比较难给类起一个合适的名字；
类中大量的方法都是集中操作类中的某几个属性。

类的职责是否设计得越单一越好？

单一职责原则通过避免设计大而全的类，避免将不相关的功能耦合在一起，来提高类的内聚性。同时，类职责单一，类依赖的和被依赖的其他类也会变少，减少了代码的耦合性，以此来实现代码的高内聚、低耦合。

但是，如果拆分得过细，实际上会适得其反，反倒会降低内聚性，也会影响代码的可维护性。

12.更多内容推荐

模块	描述	备注
GitHub	多个YC系列开源项目，包含Android组件库，以及多个案例	GitHub
博客汇总	汇聚Java，Android，C/C++，网络协议，算法，编程总结等	YCBlogs
设计模式	六大设计原则，23种设计模式，设计模式案例，面向对象思想	设计模式
Java进阶	数据设计和原理，面向对象核心思想，IO，异常，线程和并发，JVM	Java高级
网络协议	网络实际案例，网络原理和分层，Https，网络请求，故障排查	网络协议
计算机原理	计算机组成结构，框架，存储器，CPU设计，内存设计，指令编程原理，异常处理机制，IO操作和原理	计算机基础
学习C编程	C语言入门级别系统全面的学习教程，学习三到四个综合案例	C编程
C++编程	C++语言入门级别系统全面的教学教程，并发编程，核心原理	C++编程
算法实践	专栏，数组，链表，栈，队列，树，哈希，递归，查找，排序等	Leetcode
Android	基础入门，开源库解读，性能优化，Framework，方案设计	Android

23种设计模式

23种设计模式 & 描述 & 核心作用	包括
创建型模式提供创建对象用例。能够将软件模块中对象的创建和对象的使用分离	工厂模式（Factory Pattern）抽象工厂模式（Abstract Factory Pattern）单例模式（Singleton Pattern）建造者模式（Builder Pattern）原型模式（Prototype Pattern）
结构型模式关注类和对象的组合。描述如何将类或者对象结合在一起形成更大的结构	适配器模式（Adapter Pattern）桥接模式（Bridge Pattern）过滤器模式（Filter、Criteria Pattern）组合模式（Composite Pattern）装饰器模式（Decorator Pattern）外观模式（Facade Pattern）享元模式（Flyweight Pattern）代理模式（Proxy Pattern）
行为型模式特别关注对象之间的通信。主要解决的就是“类或对象之间的交互”问题	责任链模式（Chain of Responsibility Pattern）命令模式（Command Pattern）解释器模式（Interpreter Pattern）迭代器模式（Iterator Pattern）中介者模式（Mediator Pattern）备忘录模式（Memento Pattern）观察者模式（Observer Pattern）状态模式（State Pattern）空对象模式（Null Object Pattern）策略模式（Strategy Pattern）模板模式（Template Pattern）访问者模式（Visitor Pattern）

02.单一职责原则详解