用Java编写实用程序类时，有哪些好的指导方针可以遵循？
包装应该是“util”还是“utils”？是ClassUtil还是ClassUtils？什么时候是“助手”或“效用”？公用事业或公用事业？或者你使用它们的混合物？
标准Java库使用Utils和Utilities：
Apache使用各种Util和Utils，尽管主要是Utils：
Spring使用了很多Helper和Utils类：
那么，您如何命名实用程序类？
答案 0 :(得分：71)
与许多此类约定一样，重要的不是您使用的约定，而是您使用它的一致性。就像，如果你有三个实用程序类，你称之为CustomerUtil，ProductUtils和StoreUtility，其他人试图使用你的类会不断混淆并错误地键入CustomerUtils，必须查找，诅咒你几次， （我听过一次演讲的一致性演讲，演讲者用一张幻灯片显示他演讲的轮廓，标有“1”，“2”和“C”三个要点。）
永远不要让两个名字只有一些精妙的拼写不同，比如拥有CustomerUtil和CustomerUtility。如果有充分的理由做两个课程，那么他们必须有不同的东西，这个名字至少应该让我们知道这个差异是什么。如果一个包含与名称和地址相关的实用程序函数，另一个包含与订单相关的实用程序函数，则将它们称为CustomerNameAndAddressUtil和CustomerOrderUtil或其他类似函数。当我看到名字中无意义的微妙差异时，我经常疯狂。就像昨天一样，我正在制定一个有三个运费成本领域的计划，名为“货运”，“货运成本”和“费用”。我不得不研究代码来弄清楚它们之间的区别。
答案 1 :(得分：27)
Java世界中没有标准的规则/约定。但是，我更喜欢在@colinD提到的类名末尾添加“s”。
这似乎是 Master java API Designer Josh Bloch does（java集合以及Google集合）
的标准只要Helper和Util发挥作用，当有API帮助实现包的特定功能时（考虑到实现模块的包），我会称之为Helper;意味着可以在任何上下文中调用Util。
例如，在与银行帐户相关的应用程序中，所有数字特定的实用程序静态API都将转到org.mycompany.util.Numbers
所有“帐户”特定业务规则帮助API转到
org.mycompany.account.AccountHelper
毕竟，这是一个提供更好的文档和更清晰的代码的问题。
答案 2 :(得分：20)
我喜欢当类型是接口或您不控制的类时，只在类型名称中添加“s”的约定。 JDK中的示例包括Collections和Executors。它也是Google Collections中使用的惯例。
当您处理类时，您可以控制，我会说实用方法通常属于类本身。
答案 3 :(得分：8)
我认为'utils'应该是包名。类名应该指定其中逻辑的用途。添加sufix -util（s）是多余的。
答案 4 :(得分：3)
我很确定“助手”和“实用程序”这两个词可以互换使用。无论如何根据你提供的例子判断，我会说你的类名是缩写（或者它的缩写如“DomUtil”）然后调用你的包“whatever.WhateverUtil”（如果包中有多个实用程序，则调用Utils） ）。否则，如果它有一个全名而不是一个缩写，那么称之为“whatever.WhateverUtilities”。
这完全取决于你，但只要程序员知道你在谈论什么，你就会很好。如果你这样做是为了某个人的工作而专业，请在采纳我的建议之前询问他们的编码标准是什么。无论如何都要遵守商店标准，这将有助于您保住工作。 ： - ）