🗒️S 单一职责原则

Single Responsibility Principle，SRP

A class or module should have a single responsibility.

1. 一个类或者模块只负责完成一个职责或者功能

2. 不要设计大而全的类，要设计粒度小、功能单一的类

3. 单一职责原则是为了实现代码高内聚、低耦合，提高代码的复用性、可读性、可维护性

   • 从功能相关性，高内聚

   • 从功能无关性，低耦合

   • 但是如果拆得太细，反而会降低内聚性，影响可维护性

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

• 不同的应用场景、不同阶段的需求背景下，对同一个类的职责是否单一的判定可能都是不一样的

• 从不同的业务层面（粗细粒度）看待同一个类的设计，对类是否职责单一也会有不同的认识

• 评价一个类的职责是否足够单一，并没有一个非常明确的可以量化的标准，挺主观的

不过，有一些小技巧可以帮助我们从侧面判定一个类的职责是否够单一，也更具指导意义和执行性：

1. 类中的代码行数、函数或属性过多（会影响代码的可读性和可维护性）

   • 比如一个类的代码行数最好不能超过 200 行，函数个数及属性个数都最好不要超过 10 个

   • 实际上，当一个类的代码读起来让我们头大时，就说明其行数、函数、属性过多了

     • 实现某个功能时，不知道该用哪个函数了

     • 想用某个函数，翻半天都找不到时

     • 只到一个小功能却要引入整个类时（类中包含很多无关此功能实现的函数）

   • 等项目做多了代码写多了，自然就知道什么是“放盐少许”了，即所谓的“专业第六感”

2. 类依赖的其他类过多，或者依赖类的其他类过多（不符合高内聚、低耦合的设计思想）

3. 私有方法过多。可考虑将私有方法独立到新类中，设置为 public 以供更多的类使用，从而提高代码的复用性

4. 比较难给类起一个合适的名字，很难用一个业务名词概括，或者只能用一些笼统的 Manager、Context 之类的词语来命名（类的职责定义可能不够清晰）

5. 类中大量的方法都是集中操作类中的某几个属性，可考虑将这几个属性和对应的方法拆分出来

实际上，在真正的软件开发中，也没必要过于未雨绸缪，过度设计。通常，我们可以先写一个粗粒度的类以满足业务需求。随着业务的发展，如果粗粒度的类越来越庞大代码越来越多了，就可以将该粗粒度的类拆分成几个更细粒度的类，这就是常说的“持续重构”。