今天继续打卡学习极客时间上的专栏“设计模式之美”， 本篇是专栏第15节的学习笔记，介绍面向对象设计原则中的单一职责原则。

笔记

面向对象有很多经典的设计原则:

  • SOLID5原则分别是
    • 单一职责原则(SRP)、开闭原则(OCP)、里氏替换原则(LSP)、接口隔离原则(ISP)、依赖反转原则(DIP)
  • KISS - Keep It Simple, Stupid
  • YAGNI - You aren’t gonna need it
  • DRY - Don’t Repeat Yourself
  • LOD - Law of Demeter(迪米特法则，又叫做最少知识原则)

单一职责原则(SRP)

一个类或模块只负责完成一个职责(或功能)。单一职责原则是为了实现代码的高内聚、低耦合，提高代码的复用性、可读性、可维护性。 单一职责原则的定义中包含类和模块，对于模块可以从不同的范围理解：

  • 即如果从类的角度来说，单一职责原则指导我们在进行类的设计时要设计粒度小、功能单一的类，要使类保持功能单一，不应该包含两个以上业务不相干的功能。
  • 如果从更抽象的角度来理解模块，将模块理解成"微服务"。微服务的拆分上需要根据业务的边界来确定服务的边界，也是应用了单一职责的理念。

在不同场景、不同阶段的需求背景下，对同一个类的职责是否单一的判定可能是不一样的。实际中我们往往可能会先写了一个粗粒度的类，满足业务需求。随着业务的发展，如果粗粒度的类越来越大，代码越来越多，此时可以将这个粗粒度的类拆分成几个细粒度的类，这就是所谓的持续重构。

一些实用的经验，出现下面一些情况就可能说明类的设计不满足单一职责原则:

  • 类中的代码行数、函数或属性过多
  • 类依赖的其他类过多，或者依赖类的其他类过多
  • 私有方法过多
  • 比较难给类取一个合适的名字
  • 类中大量的方法都是集中操作类中的某几个属性

另外实际中也不要过度设计，类设计的过于单一也不好，实际中要以是否会提高代码的复用性、可读性、可维护性来判断。

参考