先來幾個例子

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