Java中实用程序类的命名约定
在Java中编写实用程序类时，有哪些遵循的指导原则？
包装应该是“util”还是“utils”？ 它是ClassUtil还是ClassUtils？ 什么时候上课是“助手”还是“实用”？ 实用程序或公用程序？ 或者你使用它们的混合物？
标准的Java库使用Utils和Utilities：
- javax.swing.Utilities
- javax.print.attribute.AttributeSetUtilities中
- javax.swing.plaf.basic.BasicGraphicsUtils
Apache使用各种Util和Utils，虽然大多数Utils：
- org.apache.commons.modeler.util.DomUtil
- org.apache.commons.modeler.util.IntrospectionUtils
- org.apache.commons.io.FileSystemUtils
- org.apache.lucene.wordnet.AnalyzerUtil
- org.apache.lucene.util.ArrayUtil
- org.apache.lucene.xmlparser.DOMUtils
Spring使用了很多的Helper和Utils类：
- org.springframework.web.util.UrlPathHelper
- org.springframework.core.ReflectiveVisitorHelper
- org.springframework.core.NestedExceptionUtils
- org.springframework.util.NumberUtils
那么，你如何命名你的公用事业类？
像许多这样的惯例一样，重要的不在于你使用什么约定，而是因为你一贯地使用惯例。 就像，如果你有三个实用工具类，你可以称它们为CustomerUtil，ProductUtils和StoreUtility，那么其他人试图使用你的类将会不断地感到困惑，错误地键入CustomerUtils，不得不查看它，诅咒你几次，等等（我听了一个一致的演讲，演讲者放了一张幻灯片，上面有三个要点，分别是“1”，“2”和“C”）。
永远不要做任何仅仅在一些细微的拼写上有区别的名字，比如有一个CustomerUtil和一个CustomerUtility。 如果有两个class级有充分的理由，那么他们就应该有一些不同的东西，这个名字至less应该给我们提供一个线索。 如果一个包含与名称和地址相关的效用函数，另一个包含与订单相关的效用函数，则将它们称为CustomerNameAndAddressUtil和CustomerOrderUtil等。 当我看到名字上毫无意义的细微差别时，我会经常发疯。 就像昨天一样，我正在制定一个计划，该计划有三个运费成本领域，分别叫做运费，货运成本和成本。 我不得不研究代码来弄清楚它们之间的区别是什么。
Java世界中没有这样的标准规则/惯例。 不过，我更喜欢在类名的末尾添加“s”，因为@colinD提到过。
这似乎是相当标准的什么主要的Java APIdevise师乔希布洛赫 （java集合以及谷歌收集）
只要Helper和Util去，我会调用一些帮助器，当它有API来帮助实现一个包的特定function（考虑一个包来实现一个模块）。 意味着在任何情况下都可以调用Util。
例如，在与银行账户相关的应用程序中，所有数字特定的实用程序静态API将转到org.mycompany.util.Numbers
所有“帐户”特定的业务规则，帮助API将去
org.mycompany.account.AccountHelper
毕竟，这是一个提供更好的文档和更干净的代码的问题。
当types是一个接口或一个你不能控制的类时，我喜欢只将“s”jointypes名称的约定。 JDK中的例子包括Collections和Executors 。 这也是Google Collections中使用的惯例。
当你正在处理一个你可以控制的类的时候 ，我会说实用方法通常属于类本身。
我认为'utils'应该是包名。 类名应该指定其中的逻辑的目的。 添加sufix -util（s）是多余的。
我很确定“助手”和“工具”这两个词是可以互换的。 无论如何，根据您提供的示例来判断，如果您的类名称是缩写（或者像“DomUtil”中的缩写），则请将您的包称为“whatever.WhateverUtil”（或者如果包中包含多个实用程序）。 否则，如果它有一个全名而不是缩写，那么称它为“whatever.WhateverUtilities”。
这真的取决于你，但只要编码人员知道你在说什么，你就很好。 如果你正在为专业做这个工作，那么在征求我的意见之前，问他们他们的编码标准是什么。 总是遵循商店的标准，不pipe这会帮助你保持工作。 🙂
