コードで静的クラス/シングルトンを使用して依存関係を作成することは悪い形式であり、問題を引き起こすことを読んでいます。密結合、単体テスト。
状態が関連付けられていない URL 解析メソッドのグループがあり、メソッドの入力引数のみを使用して操作を実行する状況があります。この種の方法に精通していると思います。
以前は、クラスを作成してこれらのメソッドを追加し、コードから直接呼び出していました。
UrlParser.ParseUrl(url);
しかし、ちょっと待ってください。これは、別のクラスへの依存関係を導入することです。これらの「ユーティリティ」クラスはステートレスであり、これにより前述の静的クラスとシングルトンの問題の一部が最小限に抑えられるため、これらの「ユーティリティ」クラスが悪いかどうかはわかりません。誰かがこれを明確にできますか？
メソッドを呼び出し元のクラスに移動する必要があります。つまり、呼び出し元のクラスだけがメソッドを使用する場合です。これは、「単一責任の原則」に違反する可能性があります。
理論的な設計の観点から、ユーティリティ クラスは可能な限り避けるべきものだと思います。これらは基本的に静的クラスと変わりません (ただし、状態を持たないため、わずかに優れています)。
ただし、実用的な観点からは、これらを作成し、適切な場合に使用することをお勧めします. ユーティリティ クラスを回避しようとするのは面倒なことが多く、コードの保守性が低下します。ただし、可能であれば、パブリック API でこれらを避けるように開発者に勧めています。
たとえば、あなたの場合、おそらく UrlParser.ParseUrl(...) をクラスとして扱うほうがよいと思います。BCL のSystem.Uriを見てください。これは、Uniform Resource Identifiers のクリーンで使いやすいインターフェイスを処理し、適切に機能し、実際の状態を維持します。私は、文字列に対して機能するユーティリティ メソッドよりもこのアプローチを好み、ユーザーに文字列を渡したり、検証することを忘れないようにしたりします。
いつでもインターフェースを作成し、それを静的クラスの代わりにそのインターフェースを実装するクラスのインスタンスで依存性注入で使用できます。
問題は、本当に努力する価値があるかということです。一部のシステムでは、答えはイエスですが、他のシステム、特に小規模なシステムでは、答えはおそらくノーです。
設計原則に違反しない限り、ユーティリティ クラスは問題ありません。コア フレームワーク クラスを使用するのと同じくらい楽しく使用してください。
クラスは適切な名前を付け、論理的にする必要があります。実際、それらは「ユーティリティ」というほどのものではなく、ネイティブ クラスが提供しない新たなフレームワークの一部です。
拡張メソッドのようなものを使用すると、機能を「適切な」クラスに合わせるのにも役立ちます。しかし、拡張機能は通常、拡張するクラスと一緒にパッケージ化されていないため、混乱の原因になる可能性があります。これは理想的ではありませんが、それでも非常に便利で、よりクリーンなコードを生成できます。
これは、コンテキストと使用方法に大きく依存します。
ユーティリティ クラス自体は悪くありません。しかし、使い方を誤るとダメになります。すべてのデザイン パターン (特にシングルトン パターン) は簡単にアンチパターンに変換できます。ユーティリティ クラスについても同様です。
ソフトウェア設計では、柔軟性とシンプルさのバランスが必要です。文字列操作のみを担当する StringUtils を作成する場合:
=> ユーティリティ クラス自体は悪くありません。それを悪くするのは開発者のせいです。
それはすべてコンテキストに依存します。単一の責任のみを含み、モジュールまたはレイヤー内でのみプライベートに使用されるユーティリティ クラスを作成する場合。それならまだ大丈夫です。
私は本当に、本当にそれらを避けようとしますが、誰が冗談ですか...彼らはすべてのシステムに忍び込みます. それにもかかわらず、与えられた例では、URL のさまざまな属性 (プロトコル、ドメイン、パス、クエリ文字列パラメーター) を公開する URL オブジェクトを使用します。ほとんどの場合、統計のユーティリティ クラスを作成したい場合、この種の作業を行うオブジェクトを作成することで、より多くの価値を得ることができます。
同様の方法で、パーセンテージ、通貨、電話番号などの検証を組み込んだ多くのカスタム コントロールを作成しました。これを行う前に、これらすべてのルールを持つパーサー ユーティリティ クラスがありましたが、基本的なルールを既に知っているページにコントロールをドロップするだけで非常にクリーンになります (したがって、ビジネス ロジックの検証のみを追加する必要があります)。 .
私はまだパーサー ユーティリティ クラスを保持し、これらのコントロールはその静的クラスを非表示にしますが、広範囲に使用します (すべての解析を見つけやすい 1 つの場所に保持します)。その点で、「Don't Repeat Yourself」を適用できるため、ユーティリティ クラスを使用することは許容できると考えていますが、ユーティリティを使用するコントロールやその他のオブジェクトでインスタンス化されたクラスの利点を得ることができます。
避けるべきステートフルオブジェクトの単一インスタンスを維持するのは古典的なシングルトンであり、必ずしも状態のないユーティリティクラスが悪であるとは限らないという他の回答のいくつかに同意します。また、可能であれば、これらのユーティリティ メソッドを、そうすることが理にかなっていて、そのようなメソッドが存在すると論理的に疑われるクラスに配置するという Reed の意見にも同意します。これらの静的ユーティリティ メソッドは、多くの場合、拡張メソッドの良い候補になる可能性があることを付け加えておきます。
それらは、適切に設計されている限り問題ありません (つまり、署名を時々変更する必要はありません)。
これらのユーティリティ メソッドは、1 つのことしか行わないため、頻繁に変更されることはありません。問題は、より複雑なオブジェクトを別のオブジェクトにタイトにしたい場合に発生します。それらのいずれかを変更または交換する必要がある場合、それらが高度に結合されていると、それが難しくなります。
これらのユーティリティ メソッドはそれほど頻繁には変更されないため、それほど問題ではないと言えます。
同じユーティリティメソッドを何度もコピペすると最悪だと思います。
Joshua Bloch によるこのビデオHow to design a good API and why it matter では、API (ユーティリティ ライブラリ) を設計する際に留意すべきいくつかの概念について説明しています。彼は認められた Java アーキテクトですが、内容はすべてのプログラミング言語に適用されます。
それらを控えめに使用してください。クラスにできるだけ多くのロジックを入れて、単なるデータコンテナーにならないようにする必要があります。
しかし、ユーティリティを避けることはできませんが、ユーティリティが必要になる場合もあります。
この場合は大丈夫だと思います。
参考までに、system.web.httputility クラスには、便利な一般的な http ユーティリティが多数含まれています。