Java中實用程序類的命名約定

在Java中編寫實用程序類時，有哪些遵循的指導原則？Java中實用程序類的命名約定

包裝應該是「util」還是「utils」？它是ClassUtil還是ClassUtils？什麼時候上課是「助手」還是「實用」？實用程序或公用程序？或者你使用它們的混合物？

標準Java庫同時使用的Utils和實用程序：

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使用了很多助手和utils的類：

org.springframework.web.util.UrlPathHelper
org.springframework.core.ReflectiveVisitorHelper
org.springframework.core.NestedExceptionUtils
org.springframework.util.NumberUtils

那麼，你如何命名你的公用事業類？

來源

2010-04-20 JR.

像許多這樣的慣例一樣，重要的不在於你使用什麼約定，而是因爲你一貫使用慣例。就像，如果你有三個實用程序類，並且你稱它們爲CustomerUtil，ProductUtils和StoreUtility，那麼其他人試圖使用你的類會不斷地感到困惑，並錯誤地鍵入CustomerUtils，必須查看它，詛咒你幾次，等等。（我聽到演講者的一致性，演講者放了一張幻燈片，其中有三個要點，分別標爲「1」，「2」和「C」）。

永遠不會永遠使兩個名稱僅在一些細微的拼寫方面有所不同，例如具有CustomerUtil和CustomerUtility。如果有兩個班級有充分的理由，那麼他們肯定會有不同的看法，而這個名字至少應該給我們提供一個線索。如果其中一個包含與名稱和地址相關的實用函數，另一個包含與訂單相關的實用函數，則將其稱爲CustomerNameAndAddressUtil和CustomerOrderUtil等。當我看到名字中毫無意義的微妙差異時，我經常發瘋。就像昨天一樣，我正在制定一個計劃，該計劃有三個運費成本領域，分別命名爲「運費」，「貨運成本」和「成本」。我不得不研究代碼來弄清它們之間的區別。

來源

2010-04-20 17:01:42 Jay

和第四號的IV :-) - 但是*運費*，*貨運費*，和* frght *之間的差異是什麼？ – KajMagnus 2012-03-04 08:57:06

@KayMagnus這篇文章是在一年前，但據我記得，其中之一是目前的運費成本的記錄，在改變訂單的內容，因此可能的運費成本;另一個是從一個表中抽取的標準運費;第三種是在某些特殊情況下使用的計算成本，如海外裝運。至少爲什麼他們至少不能打電話給他們，比如說「currFreight」，「stdFreight」和「calcFreight」。那至少會給出一個提示。 – Jay 2012-03-07 22:02:13

好的，感謝您的解釋:-)一個有趣的怪異代碼示例，我認爲 – KajMagnus 2012-03-08 07:28:35

我認爲'utils'應該是包名。類名應該指定其內部邏輯的用途。添加sufix -util（s）是多餘的。

來源

2010-04-20 16:15:18 Aito

這對於[按功能包裝]（http://www.javapractices.com/topic/TopicAction.do?Id=205）方法來說並不適合。 – jpangamarca 2015-12-13 18:21:35

我很確定單詞「助手」和「實用程序」可以互換使用。無論如何，根據你提供的例子來判斷，如果你的類名是一個縮寫（或者有像DomUtil這樣的縮寫），那麼就調用你的包「whatever.WhateverUtil」（或者Utils，如果你的包中有多個實用程序）。否則，如果它具有全名而不是縮寫，則稱它爲「whatever.WhateverUtilities」。

這真的取決於你，但只要編碼員知道你在說什麼，你就很好。如果你爲某人專門做這個工作，在徵求我的建議之前問他們他們的編碼標準是什麼。無論做什麼，始終遵守店鋪標準，這將有助於您保持工作。 :-)

來源

2010-04-20 16:16:14 KSwift87

我喜歡在類型是接口或不受控制的類的情況下僅將「s」添加到類型名稱的約定。 JDK中的示例包括Collections和Executors。這也是Google Collections中使用的慣例。

當你正在處理一個類你有控制權，我會說實用方法通常屬於類本身。

來源

2010-04-20 16:27:48 ColinD

谷歌番石榴也使用這種模式 – Jherico 2010-04-20 18:21:47

Java世界中沒有這樣的標準規則/約定。不過，我更喜歡在@colinD中提到的類名稱末尾加上「s」。

這似乎是非常標準的，以什麼 Master java API Designer Josh Bloch does（Java集合以及谷歌集合）

只要助手和的Util去，我會叫的東西助手時，它具有的API來幫助實現的特定功能一個包（考慮一個包來實現一個模塊）;意味着在任何情況下都可以調用Util。

例如，在有關銀行賬戶的應用程序，所有的一些具體實用靜態API會去org.mycompany.util.Numbers

所有「賬戶」的具體業務規則幫助的API會去

org.mycompany.account.AccountHelper

畢竟，這是提供更好的文檔和更簡潔的代碼的問題。

來源

2010-04-20 17:20:06

這似乎是合理的，幫手將更具體的Utils。 – KajMagnus 2012-03-04 09:04:00

是的，我喜歡這種方式，更合乎邏輯。 – Conan 2016-06-01 04:55:16

鏈接已損壞。我發現[另一個]（http://www.cs.bc.edu/~muller/teaching/cs102/s06/lib/pdf/api-design）。 – Chavjoh 2017-09-06 12:06:30

Java中實用程序類的命名約定

回答

相關問題