保持类的单一职责

在面向对象的开发过程中,类是最基本的组成单位。那么,我们如何来衡量一个类的好坏呢?

直观的讲,短小的类肯定比臃肿的类好,而更为准确的衡量方式则是看该类有没有符合单一职责。对于类的单一职责,很多开发者做不到,可能有以下原因

  1. 精力或者能力有限,只关心实现,不关心代码的整洁性;
  2. 认为将所有的东西放在一个类中更加直观,方便管理。一是可以避免方法过多,二是可以避免方法之间的跳转。

持有该观点的人可能只是为了贪求写代码的一时方便,他们明显忽略了保持类的单一职责的好处。至少,有两点好处是显而易见的:

  1. 类很好的组织在了一起,除了方便测试外,后期修改的时候风险将会降到最低;
  2. 单一职责就好像一个个组块一样,其实更有利于管理和记忆;

那么,怎么看类有没有符合单一职责呢?主要有以下几点

  1. 从命名角度看,命名能够直接体现出单一职责,如果一个类的命名没有明确的体现出它的职责,那么该类很可能需要进一步重构。
  2. 从修改的角度看,一个类应该有且只有一个修改的它的理由,如果有多个理由修改该类,那么该类就不符合单一职责。
  3. 从内聚性的角度,类的内聚性要高。具体的讲,就是类成员与类方法高度关联,如果类的方法都用到了各个成员,那么该类的内聚性就是极高的。

最后,介绍一下一个基本的重构思路

  1. 首先,一个类中的方法之间在互相调用,应该少直接传递参数,而是将参数提升到类成员中,然后通过访问类成员的方式来获取需要的参数。
  2. 一旦这么做之后,你就会逐渐发现一些方法共享这些成员,另外一些方法共享其他成员。这样的话,就可以进行拆分了,拆分后的类就能够保持更高的内聚性。
本作品采用《CC 协议》,转载必须注明作者和本文链接
讨论数量: 0
(= ̄ω ̄=)··· 暂无内容!

讨论应以学习和精进为目的。请勿发布不友善或者负能量的内容,与人为善,比聪明更重要!