私は時々、実際には他の場所に属していないように見えるメソッドと値を保持するのに役立つ「Util」クラスを作成します。しかし、これらのクラスの1つを作成するたびに、「あー、これを後悔するつもりだ...」と思うのは、どこかで悪いことを読んだからです。

しかし、他方では、2つの説得力のある（少なくとも私にとって）ケースがあるようです。

1. パッケージ内の複数のクラスで使用される実装の秘密
2. インターフェイスを乱雑にすることなく、クラスを増強するための便利な機能を提供します

私は破壊に向かっていますか？あなたが言うこと ！！リファクタリングする必要がありますか？

現代のオブジェクト指向デザインは、すべてがオブジェクトではないことを受け入れています。いくつかのことは行動、または式であり、それらのいくつかは状態を持っていません。これらのことを純粋な関数としてモデル化して、その設計の利点を得るのは良いことです。

JavaとC＃（およびその他）では、utilクラスを作成し、そのフープをジャンプして実行する必要があります。迷惑ですが、世界の終わりではありません。設計の観点からはそれほど面倒ではありません。

絶対とは絶対言うな"

私はそれが必ずしも悪いとは思わない、あなたがそれをひどくし、それを乱用した場合にのみ悪い。

ツールとユーティリティが必要

まず最初に、私たちは皆、ほとんどどこにでもあると思われるライブラリを使用しています。たとえば、Javaの世界では、Google GuavaまたはApache Commonsの一部（Apache Commons Lang、Apache Commons Collectionsなど）。

したがって、明らかにこれらが必要です。

ハードワード、重複、バグの導入を避ける

あなたはこれらを考えるならば、かなりこれらのちょうど非常に大きな集まりですUtil誰かが彼らの（比較的）が権利を取得するために偉大な長さを経て、彼らがしてきた以外、あなたが記述するクラスの時間 - テストと大きく目を球状に他人による。

だから、Utilクラスを書くことを悩むときの最初の経験則は、そのUtilクラスが実際に存在しないことを確認することだと思います。

私が見た唯一の反論は、依存関係を制限したいときです：

• 依存関係のメモリフットプリントを制限したい場合、
• または、開発者が使用できるものを厳密に制御したい場合（強迫観念の大規模なチームで発生する場合、または特定のフレームワークがどこかで絶対に回避するための奇妙な超クラッピークラスを持つことが知られている場合）。

ただし、ProGuardまたは同等のものを使用してライブラリを再パッケージ化するか、自分で分解することで、これらの両方に対処できます（Mavenユーザーの場合、maven-shade-pluginは、ビルドの一部としてこれを統合するためのフィルターパターンを提供します）。

そのため、ライブラリ内にあり、ユースケースと一致し、それ以外のベンチマークが示されていない場合は、それを使用します。それがあなたのものと少し異なる場合は、それを（可能であれば）拡張するか、拡張するか、最後の手段で書き直してください。

命名規則

しかし、これまでのところ、この回答では、私はそれらをUtilあなたのように呼んでいます。それらに名前を付けないでください。

意味のある名前を付けてください。Google Guavaを（非常に）非常に良い例として取り上げて、com.google.guava名前空間が実際にあなたのutilルートであると想像してください。

util最悪の場合はパッケージを呼び出しますが、クラスは呼び出しません。Stringオブジェクトと文字列構造の操作を扱う場合は、それを呼び出さStringsないでくださいStringUtils（申し訳ありませんが、Apache Commons Lang-私は今でも好きで、使っています！）。特定の処理を行う場合は、特定のクラス名（SplitterまたはなどJoiner）を選択します。

単体テスト

これらのユーティリティの作成に頼る必要がある場合は、必ずユニットテストを行ってください。ユーティリティーの良いところは、通常、自己完結型のコンポーネントであり、特定の入力を受け取り、特定の出力を返すことです。それがコンセプトです。そのため、それらを単体テストしない理由はありません。

また、単体テストでは、APIのコントラクトを定義および文書化できます。テストが壊れた場合、何かを間違った方法で変更したか、APIのコントラクトを変更しようとしていることを意味します^{（または、元のテストはがらくたでした-そこから学び、二度としないでください）}。

APIデザイン

これらのAPIについての設計上の決定は、おそらくあなたに長い間続くでしょう。そのため、Splitter-cloneの作成に何時間も費やさずに、問題へのアプローチに注意してください。

いくつか質問をしてください：

• あなたのユーティリティメソッドは、クラスをそれ自体で保証しますか、それとも同様に有用なメソッドのグループの一部であることが理にかなっている場合、静的メソッドで十分ですか？
• オブジェクトを作成し、APIをより読みやすくするためにファクトリメソッドが必要ですか？
• 読みやすさと言えば、Fluent APIやBuilderなどが必要ですか？

これらのユーティリティは、幅広いユースケースをカバーし、堅牢で安定し、十分に文書化され、最小限の驚きの原則に従って、自己完結型であることが必要です。理想的には、utilsの各サブパッケージ、または少なくともutilパッケージ全体をバンドルにエクスポートして、簡単に再利用できるようにする必要があります。

いつものように、ここで巨人から学びます：

• これらをふるいにかけ、分析して比較し、頻繁に戻ってもう一度やり直します^{（これらが絶対的または部分的に良いか悪いかについては判断していないことに注意してください、分析と比較ビットに重点が置かれています）}：
  • Javaのutilパッケージ（コレクションライブラリが含まれています）、そのネットと同等、
  • Google GuavaとApache Commons、
  • C ++のSTLとブースト、
  • Scalaのコレクション ライブラリとscalaz、
  • 基本に戻り、goo ol 'lib Cを見てください。
• Josh Blochの「優れたAPIを設計する方法と重要な理由」をご覧ください（スライド）。
• 追加のBloch資料を読んで見てください：
  • 効果的なJava（Bloch、2008）、
  • Java Puzzlers（Bloch、Gafter、2005）、
  • Javaオブジェクトの作成。
• API設計事項をお読みください。

^{はい、これらの多くはコレクションとデータ構造に重点を置いていますが、ほとんどまたはすべてのユーティリティを直接または間接的に実装する可能性が高いとは言いません。}

Utilクラスは凝集性がなく、一般に、クラスは変更する単一の理由（単一責任原則）を持たなければならないため、設計が悪いです。

しかし、私のような、非常にJava APIのクラス「UTIL」を見てきました：Math、CollectionsとArrays。

実際、これらはユーティリティクラスですが、それらのメソッドはすべて単一のテーマに関連しています。1つは数学演算、1つはコレクションを操作するメソッド、もう1つは配列を操作するメソッドがあります。

ユーティリティクラスにまったく関係のないメソッドがないようにしてください。その場合、実際に所属する場所以外に配置することもできます。

utilクラスが必要な場合は、Java やのようなテーマで区切るようMathにCollectionsしてくださいArrays。少なくとも、名前空間にすぎない場合でも、設計の意図を示しています。

私は、ユーティリティクラスを常に避け、作成する必要はありませんでした。

utilクラスを使用することは完全に許容できますが、という用語を好みClassNameHelperます。.NET BCLにはヘルパークラスも含まれています。覚えておくべき最も重要なことは、クラスの目的と個々のヘルパーメソッドを徹底的に文書化し、それを高品質で保守可能なコードにすることです。

また、ヘルパークラスに夢中にならないでください。

私は2段階のアプローチを使用します。「util」パッケージ（フォルダ）内の「Globals」クラス。何かが「Globals」クラスまたは「util」パッケージに入るには、次の条件が必要です。

1. シンプル、
2. 変わらない、
3. アプリケーションの他の要素に依存しない

これらのテストに合格する例：

• システム全体の日付および10進形式
• EARLIEST_YEAR（システムがサポートする）やIS_TEST_MODEなどの不変のグローバルデータ、または真にグローバルで変化しない（システムの実行中）値。
• 言語、フレームワーク、またはツールキットのギャップを回避する非常に小さなヘルパーメソッド

以下は、アプリケーションの他の部分から完全に独立した非常に小さなヘルパーメソッドの例です。

public static String ordinal(final int i) {
    return (i == 1) ? "1st" :
           (i == 2) ? "2nd" :
           (i == 3) ? "3rd" :
           new StringBuilder().append(i).append("th").toString();
}

これを見ると、21が「21番」、22が「22番」などであるというバグがありますが、それは重要なことです。

これらのヘルパーメソッドの1つが大きくなるか複雑になる場合は、utilパッケージ内の独自のクラスに移動する必要があります。utilパッケージ内の2つ以上のヘルパークラスが相互に関連している場合、それらを独自のパッケージに移動する必要があります。定数またはヘルパーメソッドがアプリケーションの特定の部分に関連していることが判明した場合は、そこに移動する必要があります。

Globalsクラスまたはutilパッケージにこだわるすべてのものに適した場所がない理由を正当化でき、上記のテストを使用して定期的にクリーニングする必要があります。それ以外の場合は、混乱を作成しているだけです。