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

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

先来几个例子

• 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。