先來幾個例子
- 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。