私はこのスレッドを見ました
「Utilities」クラスが邪悪な場合、どこに汎用コードを配置すればよいですか？
そして、なぜユーティリティクラスは邪悪なのでしょうか？
何十ものクラスのドメインモデルがあるとします。インスタンスをxml化できるようにする必要があります。親でtoXmlメソッドを作成しますか？MyDomainXmlUtility.toXmlヘルパークラスを作成しますか？これは、ビジネスニーズがドメインモデル全体にまたがる場合です-インスタンスメソッドとして本当に属していますか？アプリケーションのxml機能に多数の補助メソッドがある場合はどうでしょうか？
回答:
ユーティリティクラスは厳密に悪いわけではありませんが、優れたオブジェクト指向設計を構成する原則に違反する可能性があります。優れたオブジェクト指向設計では、ほとんどのクラスは単一のものとそのすべての属性と操作を表す必要があります。モノを操作している場合、そのメソッドはおそらくそのモノのメンバーである必要があります。
ただし、ユーティリティクラスを使用していくつかのメソッドをグループ化できる場合があります。たとえばjava.util.Collections、Javaコレクションで使用できるいくつかのユーティリティを提供するクラスです。これらは特定の種類のコレクションに固有のものではなく、任意のコレクションで使用できるアルゴリズムを実装しています。
本当に、あなたがする必要があるのはあなたのデザインについて考え、それがメソッドを置くのに最も意味がある場所を決定することです。通常、これはクラス内の操作です。ただし、場合によっては、実際にユーティリティクラスとして使用されることもあります。ただし、ユーティリティクラスを使用する場合は、ランダムなメソッドを投げるだけでなく、目的と機能ごとにメソッドを整理します。
一般的なコンセンサスは、ユーティリティクラス自体は悪ではないということです。あなたはそれらを慎重に使う必要があります：
静的ユーティリティメソッドを一般的で再利用できるように設計します。それらがステートレスであることを確認してください。つまり、静的変数はありません。
ユーティリティメソッドが多数ある場合は、開発者が見つけやすいようにクラスに分割します。
ドメインクラスの静的メソッドまたはインスタンスメソッドの方が適切なソリューションである場合は、ユーティリティクラスを使用しないでください。たとえば、抽象基本クラスまたはインスタンス化可能なヘルパークラスのメソッドがより良いソリューションであるかどうかを検討します。
Java 8以降では、インターフェイスの「デフォルトメソッド」がユーティリティクラスよりも優れたオプションである場合があります。（たとえば、Java 8のデフォルトメソッドと抽象クラスのインターフェイスを参照してください。）
この質問を見るもう1つの方法は、引用された質問で、「ユーティリティクラスが「悪」である場合」がストローマンの議論であることを観察することです。それは私の質問のようです：
「豚が飛べるなら傘を持ってもいいですか？」
上記の質問では、私は実際には豚が飛ぶことができることを言っていないです...または私は、彼らがいることを命題に同意することができ飛びます。
典型的な「xyz is evil」の発言は、極端な視点でポーズをとって考えさせる修辞的な装置です。それらはめったに（もしあれば）文字通りの事実の陳述として意図されていません。
ユーティリティクラスは、それらをサポートするデータで責任をグループ化できないため、問題があります。
ただし、これらは非常に有用であり、永続的な構造として、またはより完全なリファクタリングの際の踏み台として、常に作成しています。
よりクリーンなコード視点ユーティリティクラスは、単一の責任とオープン・クローズの原則に違反します。それらには変更する理由がたくさんあり、設計上拡張可能ではありません。これらは、中間リフティングとしてリファクタリング中にのみ存在する必要があります。
classキーワードが使用されている場合でも。それは名前空間のように
x.equals(y)1ので、私は置くことを意図したことはありません））、これは本当に伝えていない（と私は実装を知らないことに頼ることはできません一切の状態を変更するべきではないという事実）2 x」にy3）と比較した場合の「優先」または「実行」の位置。「の同一性」を検討したくない、xまたはy単にその値に関心があるだけ。
私はそれが邪悪になり始めると思います
1）大きすぎます（この場合は、意味のあるカテゴリにグループ化してください）。
2）静的メソッドであってはならないメソッドが存在する
しかし、これらの条件が満たされない限り、それらは非常に役立つと思います。
Widget.compareTo(Widget widget)と静的を比較してくださいWidgetUtils.compare(Widget widgetOne, Widget widgetTwo)。比較は静的に行うべきではないものの例です。
この問題は、次の2つの観点から見ることができます。
*Util方法は、多くの場合、不適切なコード設計または遅延命名規則の提案です。utilクラス/モジュールの正しい使用法。外部ライブラリの例ローンやクレジットカードを管理するアプリケーションを作成しているとしましょう。これらのモジュールからのデータは、Webサービスを通じてjson形式で公開されます。理論的には、手動でオブジェクトをに含まれる文字列に変換できますがjson、これはホイールを再発明します。正しい解決策は、Javaオブジェクトを目的の形式に変換するために使用される外部ライブラリを両方のモジュールに含めることです。（例の画像ではgsonを示しています）
utilクラス/モジュールの正しい使用法。util他のチームメンバーに言い訳なしで独自に書くユースケースとして、2つのアプリケーションモジュールでいくつかの計算を実行する必要があると仮定しますが、どちらもポーランドに祝日があることを知る必要があります。理論的にはモジュール内でこれらの計算を行うことができますが、この機能を個別のモジュールに抽出する方が良いでしょう。
これは小さいですが、重要な詳細です。あなたが書いたクラス/モジュールはとは呼ばれずHolidayUtil、と呼ばれますPolishHolidayCalculator。機能的にはutilクラスですが、一般的な言葉は避けました。
ここでこの質問を振り返ると、C＃拡張メソッドはユーティリティクラスの必要性を完全に破壊すると思います。しかし、すべての言語にそのような天才的な構成があるわけではありません。
また、JavaScriptがあり、新しい関数を既存のオブジェクトに直接追加できます。
しかし、C ++のような古い言語でこの問題を解決するエレガントな方法が本当にあるかどうかはわかりません...
Good OOを書くのはちょっと難しいし、見つけるのも難しいです。GoodOOを書くには、適切な機能コードを書くよりも多くの時間と知識が必要です。
そして、予算が限られているとき、上司はあなたがたくさんのクラスを書いて一日中過ごしたことをいつも喜んでいるわけではありません...
ユーティリティクラスが悪であることに完全に同意しません。
ユーティリティクラスは、いくつかの点でOOプリンシパルに違反する可能性がありますが、必ずしも悪いわけではありません。
たとえば、valueに一致するすべての部分文字列の文字列をクリーンアップする関数が必要だとしますx。
stl c ++（現在）はこれを直接サポートしていません。
のポリモーフィック拡張を作成できますstd::string。
しかし問題は、プロジェクトで使用するすべての文字列を拡張文字列クラスにしたいですか？
OOが実際に意味をなさない場合がありますが、これはその1つです。私たちはプログラムを他のプログラムと互換性があるようにしたいのでstd::string、クラスStringUtil_（または何か）に固執して作成します。
クラスごとに1つのユーティリティを使用するのがベストだと思います。すべてのクラスに1つのユーティリティを使用するか、1つのクラスに多くのユーティリティを使用するのはばかげていると思います。
ほとんどのUtilクラスは、次の理由で不良です。
静的ライブラリと動的ライブラリにはいくつかの類似点があります。
クラスにメソッドを追加できない場合（たとえば、Accountジュニア開発者による変更に対してロックされている場合）は、次のように、いくつかの静的メソッドをUtilitiesクラスに追加します。
public static int method01_Account(Object o, String... args) {
Account acc = (Account)o;
...
return acc.getInt();
}
Accountます。またはより良いのは、ロックしないソース管理システムです。
Accountがジュニア開発者がそれを変更できないようにファイルがロックされたことを意味したと思います。ジュニア開発者として、それを回避するために、彼は上記のようにしました。そうは言っても、ファイルへの書き込みアクセス権を取得して適切に実行する方が良いでしょう。