SOLID 原则

由 5 个设计原则组成的,它们分别是:单一职责原则、开闭原则、里式替换原则、接口隔离原则和依赖反转原则,依次对应 SOLID 中的 S、O、L、I、D 这 5 个英文字母。

单一职责原则定义

英文:Single Responsibility Principle,缩写为 SRP。描述:A class or module should have a single responsibility,一个类或者模块只负责完成一个职责(或者功能)

通俗来讲,就是一个类只负责完成一个职责或者功能,不要设计大而全的类,要设计颗粒度小、功能单一的类。换个角度说,一个类包含了两个或者两个以上业务不相干的功能,那就可以认为它的职责不够单一,应该将它拆分成多个功能单一、粒度更细的类。

判断职责是否足够单一

从类的定义来看,判断类的职责是否足够单一看似很简单,其实不然。

评价一个类的职责是否足够单一,并没有一个非常明确的,可以量化的标准。在真正的软件开发中,也没有必要过于未雨绸缪,过度设计。可以先写一个粗粒度的类,满足业务需求。随着业务的发展,如果粗粒度的类越来越庞大,代码越来越多,这个时候,就可以将这个粗粒度的类,拆分成几个更细烈度的类。这就是所谓的持续重构。

几条判断原则:

  • 类中的代码行数、函数或属性过多,会影响代码的可读性和可维护性。
  • 类依赖的其他类过多,或者依赖类的其他类过多,不符合高内聚、低耦合的设计思想。
  • 私有方法过多,我们就要考虑能否将私有方法独立到新的类中,设置为 public 方法,供更多的类使用,从而提高代码的复用性。
  • 比较难给类起一个合适名字,很难用一个业务名词概括。
  • 类中大量的方法都是集中操作类中的某几个属性。

类的职责越单一越好?

为了满足单一职责原则,是不是把类拆得越细就越好呢?答案是否定的。

单一职责原则通过避免设计大而全的类,避免将不相关的功能耦合在一起,来提高类的内聚性。同时,类职责单一,类依赖的和被依赖的其他类也会变少,减少了代码的耦合性,以此来实现代码的高内聚、低耦合。但是,如果拆分得过细,实际上会适得其反,反倒会降低内聚性,也会影响代码的可维护性。

讨论

问:对于如何判断一个类是否职责单一,如何判断代码行数过多,还有哪些其他的方法吗?

职责:该类对与其他类而言是否为“黑盒”。

代码行数:方法间是否存在重复代码?方法间是否有足够的复用性?部分方法是否可以被其他类是否?属性对该类是否必要,需要移除吗?

问:单一职责原则,除了应用到类的设计上,还能延伸到哪些其他设计方面吗?

方法,模块,功能点等。