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。
ソース

82

このような多くの規約と同様に、一貫して使用するため、重要なことは、使用する規約ほどではありません。たとえば、3つのユーティリティクラスがあり、それらをCustomerUtil、ProductUtils、およびStoreUtilityと呼ぶ場合、クラスを使用しようとする他の人々は常に混乱し、誤ってCustomerUtilsと入力し、調べて、何度か呪いをかけます。など（一貫性についての講義を一度聞いたが、講演者は自分のスピーチの概要を「1」、「2番目」、「C」という3つの主要なポイントでスライドに示した。）

CustomerUtilとCustomerUtilityのように、微妙なスペルだけが異なる2つの名前を作成することはありません。2つのクラスを作成する正当な理由がある場合は、クラスに異なるものがあるはずです。名前から、少なくともその違いが何かわかるようになります。1つに名前と住所に関連するユーティリティ関数が含まれ、もう1つに注文に関連するユーティリティ関数が含まれている場合は、CustomerNameAndAddressUtilおよびCustomerOrderUtilなどを呼び出します。名前に微妙な意味のない微妙な違いが見られるとき、私は定期的に気が狂います。昨日のように、「freight」、「freightcost」、「frght」という3つの運賃フィールドのプログラムに取り組んでいました。コードを調べて、それらの違いを理解する必要がありました。

— ジェイ
ソース

9

そして、数4 :-)のためのIV -しかし、何だったの違い貨物、freightcost、およびfrghtは？

— KajMagnus

4

@KayMagnusその投稿は1年以上前でしたが、覚えているように、それらの1つは、注文内容を変更する前のレコードの現在の運賃でした。もう1つは、テーブルから取得した標準の運賃です。3つ目は、海外発送などの一部の特殊なケースで使用される計算コストです。「currFreight」、「stdFreight」、「calcFreight」のように、少なくともそれらを呼び出せなかった理由と同様です。それは少なくともクルードを与えていただろう。

— ジェイ

わかりました、説明に感謝します:-)面白い奇妙なコードの例だと思います

— KajMagnus

31

これについては、Javaの世界には標準の規則や慣習はありません。ただし、@ colinDで述べたように、クラス名の最後に「s」を追加することをお勧めします。

これは、Master Java API DesignerのJosh Blochが行うことのかなり標準的なようです（JavaコレクションとGoogleコレクション）。

HelperとUtilが続く限り、パッケージの特定の機能を実現するのに役立つAPI（パッケージをモジュールとして実装することを考慮）がある場合は、ヘルパーと呼びます。Utilはどのような状況でも呼び出される可能性があることを意味します。

たとえば、銀行口座に関連するアプリケーションでは、特定のユーティリティの静的APIはすべて次のようになります。 org.mycompany.util.Numbers

APIを支援するすべての「アカウント」固有のビジネスルールは、

org.mycompany.account.AccountHelper

結局のところ、それはより良いドキュメントとよりクリーンなコードを提供することの問題です。

— リングベアラー
ソース

5

ヘルパーはUtilsよりも具体的です。

— KajMagnus

1

はい、私はこのアプローチが好きです。より論理的です。

— コナン

3

リンクが壊れています。別を見つけた。

— Chavjoh 2017

22

型が制御できないインターフェースまたはクラスの場合、型名に「s」を追加するだけの慣習が好きです。JDKでの例には、Collectionsおよびが含まれExecutorsます。これは、Googleコレクションで使用される規則でもあります。

自分が制御できるクラスを扱う場合、ユーティリティメソッドは一般的にクラス自体に属していると思います。

— ColinD
ソース

2

Google Guavaもこのパターンを使用しています

— Jherico 2010

11

「utils」はパッケージ名だと思います。クラス名は、その中のロジックの目的を指定する必要があります。sufix -util（s）の追加は冗長です。

— あいとう
ソース

2

これは、「機能ごとのパッケージ」アプローチで行うには適切ではありません。

— jpangamarca

1

@jpangamarcaリンクした記事には、「機能別パッケージ」の例に「util」パッケージがあります。実際には、ある種のユーティリティ機能/レイヤーは避けられないことが多いと思います。

— kapex

1

@kapex筆者による見落とし。tld.organization.app.utilパッケージは、（できましたが、すべきではない）が存在してはならない、任意の数のtld.organization.app.feature.utilパッケージが完全に罰金です。

— jpangamarca

3

「ヘルパー」と「ユーティリティ」は同じ意味で使われていると思います。とにかく、あなたが提供した例で判断すると、あなたのクラス名が略語である（または「DomUtil」のように略語がある）場合は、パッケージを「whatever.WhateverUtil」（または、パッケージに複数のユーティリティがある場合はUtils）と呼びます。）。それ以外に、省略形ではなくフルネームがある場合は、「whatever.WhateverUtilities」と呼びます。

それはあなた次第ですが、プログラマーがあなたが話していることを知っている限り、あなたは大丈夫です。誰かのために仕事としてこれを専門的にやっているなら、私のアドバイスをする前に彼らのコーディング標準が何であるか彼らに尋ねてください。それがあなたがあなたの仕事を続けるのを助けるので、それがどんなものであっても、常に店の基準に行ってください。:-)

— KSwift87
ソース