Java中实用程序类的命名约定

115

用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

那么，您如何命名实用程序类？

java naming-conventions

— JR
source

82

像许多此类约定一样，重要的不是使用什么约定，而是要始终使用它。例如，如果您有三个实用程序类，并且将它们称为CustomerUtil，ProductUtils和StoreUtility，则其他尝试使用您的类的人将不断感到困惑，并错误地键入CustomerUtils，必须对其进行查找，并多次诅咒您，等等。（我曾经听过一次关于一致性的演讲，演讲者放了一张幻灯片，用三个要点分别标明了演讲的要点，分别标记为“ 1”，“ 2nd”和“ C”。）

从来没有两个名字只是在一些细微的拼写上有所不同，例如拥有CustomerUtil和CustomerUtility。如果有充分的理由进行两个类的学习，那么它们必须有所不同，而且名称至少应为我们提供一个区别的线索。如果一个包含与名称和地址相关的实用程序功能，而另一个包含与订单相关的实用程序功能，则将它们称为CustomerNameAndAddressUtil和CustomerOrderUtil或类似的名称。当我看到名字无意义的细微差别时，我会经常发疯。就像昨天一样，我正在开发一个程序，该程序包含三个字段的运费，分别为“运费”，“运费”和“运费”。我必须研究代码以找出它们之间的区别。

— 周杰伦
source

9

和IV的4号:-) -但是，什么是之间的差别运价，freightcost和frght？

— KajMagnus 2012年

4

@KayMagnus那个帖子是一年多以前的，但是我记得，其中之一是记录的当前运费，在更改订单内容之前，因此可能是运费。另一个是从表中得出的标准运费；第三个是在某些特殊情况下使用的计算成本，例如海外装运。就像为什么他们至少不能给他们打电话，说“ currFreight”，“ stdFreight”和“ calcFreight”。那至少会带来一个惊喜。

— 2012年

好的，谢谢您的解释：-)我认为这是一个有趣的怪异代码示例

— KajMagnus

31

Java世界中没有为此的标准规则/惯例。但是，我更喜欢@colinD提到的在类名末尾添加“ s”。

这似乎是Master Java API Designer Josh Bloch所做的工作的标准（Java集合以及Google集合）

只要有Helper和Util，当它具有有助于实现程序包特定功能的API（考虑将程序包实现模块）时，我将称其为Helper。意味着在任何情况下都可以调用Util。

例如，在与银行帐户相关的应用程序中，所有特定于数字的实用程序静态API都将转到 org.mycompany.util.Numbers

所有“帐户”特定的业务规则帮助API都将转到

org.mycompany.account.AccountHelper

毕竟，这是提供更好的文档和更干净的代码的问题。

— 环形承载
source

5

这似乎是合理的，Helper比Utils更具体。

— KajMagnus 2012年

1

是的，我喜欢这种方法，这更合乎逻辑。

— 科南2016年

3

链接断开。我找到了另一个。

— Chavjoh

22

我喜欢这样的约定：当类型是您无法控制的接口或类时，只需在类型名称上添加“ s”。JDK中的示例包括Collections和Executors。这也是Google收藏夹中使用的约定。

当您处理可以控制的类时，我会说实用程序方法通常属于该类本身。

— 科林
source

2

Google Guava也使用这种模式

— Jherico 2010年

11

我认为'utils'应该是程序包名称。类名应指定内部逻辑的用途。添加sufix -util是多余的。

— 爱藤
source

2

在“按功能打包”方法中，这不是正确的选择。

— jpangamarca 2015年

1

@jpangamarca在示例中，链接的文章在“按功能打包”示例中有一个“ util”包。我认为在实践中通常无法避免某种实用程序功能/层。

— kapex

1

@kapex我想是作者的疏忽。一个tld.organization.app.util软件包不应该存在（可以，但是不应该），任何数量的tld.organization.app.feature.util软件包都可以。

— jpangamarca

3

我很确定“助手”和“实用程序”这两个词可以互换使用。无论如何，从您提供的示例来看，我要说的是，如果您的类名是缩写（或其中有缩写，例如“ DomUtil”），则将您的包称为“ whatever.WhateverUtil”（如果包中包含多个实用程序，则称为Utils。）。否则，如果它具有全名而不是缩写，则将其称为“ whatever.WhateverUtilities”。

这实际上取决于您，但是只要编码人员知道您在说什么，您就可以做到。如果您是为了某人而专业地从事这项工作，请在征询我的建议之前先询问他们的编码标准是什么。始终遵循商店标准，因为这将帮助您保持工作。:-)

— 迅捷87
source