Java中的工具类究竟如何命名?

6,640 阅读4分钟

先来几个例子

  • JDK自带工具类
Arrays.asList();
Objects.equals();
Collections.sort();
  • Spring框架工具类
StringUtils.isEmpty();
CollectionUtils.isEmpty()
FileCopyUtils.copy();
  • Hutool工具类
StrUtil.isEmpty();
CollectionUtil.isEmpty();
FileUtil.copy();


我们发现各组例子之间的命名方式均不一样,总结一下分为三种:

1、JDK主要以操作对象的复数形式命名
2、Spring框架的工具类以对象或用途 + Util复数方式命名
3、Hutool框架的工具类则以对象或用途 + Util单数方式命名

OK,看完上面的再看下我们项目中的工具类命名方式

 StringUtil.isEmpty();
 StringUtils.isEmpty();
 StringKit.isEmpty();
 StringHelper.isEmpty();
 StringTool.isEmpty();
 StringTools.isEmpty();


可以看到一个简单的String工具类就可以有这么多命名方式,可谓是集百家之长,相当丰富。

几种命名方式的比较

JDK为代表的对象复数形式


优点
简单明了,熟悉的人这么用其实蛮爽的。

缺点
容易与其他以s结尾的单词让人对类的作用产生误解,例如将News、Goods等pojo类跟Objects工具类放一起。是不是第一感觉它们是同一用途,实则不然。

Spring框架为代表的对象Util复数形式


优点
能从类名上对类的用途进行划分,使用者不容易产生误解。

缺点
类命名一般为单数,复数命名形式会显得整体命名方式不一致。

Hutool框架为代表的对象Util单数形式


优点
能从类名上对类的用途进行划分,使用者不容易产生误解,且整体命名方式容易与项目其他类保持一致。
  
缺点
这样就OK了,再较真就没法玩了。

项目中的命名方式


此处不对项目中的Kit、Tool等命名做过多讨论,主要还是对主流的几种命名方式进行分析。

到底如何命名 ?


对于纯粹的工具类来说,行业中普遍还是以Util或Utils命名方式居多,其他命名方式当然也可以使用,包括上面所列举的项目中的几种命名方式,只是说大家提到Util或Utils第一反应都知道是工具类,其他的命名方式或许需要反应个几秒钟。

但是这里需要说一下Util与Helper的区别,也仅限自己的理解。

在软件架构中有个软件重用的概念,分为水平式重用与垂直式重用。

水平式重用:是指可以在不同应用领域中使用的软件元素,简单理解就是业务无关性,可以在任意业务场景中使用

垂直式重用:是指在一类或具有较多公共性的应用领域之间进行软部件重用,简单理解就是可以在特定的业务领域或业务场景中使用


那么Util类就属于上面所说的水平式重用,Util类更多是对JDK提供的类进行封装,或者是某一技术框架自己提供的对框架内部其他类的使用封装,但是这类一般都具有业务、领域的无关性。在任何业务、领域下均可使用。所以既然是工具类一定保证其水平式重用这一特性。

Helper翻译过来助手/帮手,从字面意思来看,这样的类是作为辅助类来使用的,那么问题来了,辅助的对象是谁 ?那么当然是对别的类的辅助,这里就有个范围,哪些类可以被辅助,理论上所有类或对象如果需要都可以被辅助,但实际中更多是为了简化某一场景下相关类使用的复杂度,而提供了便捷的访问接口,形成Helper类,而这个场景一般具有业务或领域特征,所以更多体现的使用垂直式重用

总结

我个人来说目前习惯使用Util单数形式命名,项目中的其他类均以单数形式命名,如:UserController、UserVo这样的,突然出现一个复数形式的类会感觉有点突兀。

没什么特殊要求或个人癖好的情况下,还是以Util或Utils大众最容易理解的方式进行命名,你说我非要用Tool命名咋的了,这么干也没问题,关键在于公司或团队有一套自己的标准就行,我是一个有代码洁癖的人,团队中的规范标准我都会进行严格统一,前期看似需要花费不少时间,但当内部大家认知能够达成一致时,越往后团队中大家工作的默契度越高这样能最大程度减少沟通成本,减小后期的维护成本。

如果能满足以上需求,怎么命名真的都OK。