静的クラスはほとんど常に眉をひそめていますか、それともそれらを使用するのに良い時期はありますか?
たとえば、静的クラスのセキュリティなど、アプリケーションに遍在するものを実装することは理にかなっていますか?静的クラスでプロパティインジェクションを使用して実装を変更することもできます。MEFのようなものを使用して実装をインジェクトする場合は、テストの邪魔にならないだろうと思います。
静的クラスはほとんど常に眉をひそめていますか、それともそれらを使用するのに良い時期はありますか?
たとえば、静的クラスのセキュリティなど、アプリケーションに遍在するものを実装することは理にかなっていますか?静的クラスでプロパティインジェクションを使用して実装を変更することもできます。MEFのようなものを使用して実装をインジェクトする場合は、テストの邪魔にならないだろうと思います。
私は主にステートレスヘルパークラスと拡張メソッドを作成するときに静的クラスを使用します。おっしゃるように、テストの邪魔になる可能性があるため、状態のある静的クラスは避けようとしています。
静的クラスに状態を追加することにしたとしましょう。状態に依存するこのクラスのメソッドをテストするには、テスト中にこの状態を変更する方法を見つける必要があります。これは、次のことを行う必要があることを意味します。
これは、クラスが危険な可能性のある状態を変更する方法を(内部メソッドまたは内部プロパティセッターを使用して)提供する必要があることを意味します。不変のクラスまたは実装の詳細を完全にカプセル化するクラスを作成する場合、それらを簡単にテストすることはできず(まったくテストできない場合)、実装の変更によってテストが頻繁に失敗する可能性があります。MEFを使用しても、これを行うのは簡単ではありません。
もちろん、静的クラスは、ロギングや、質問で述べたように、セキュリティなどの問題に対して魅力的なソリューションを提供する場合があります。これらの場合、私はすべての呼び出しをフィールドstatic class
に委任するaを選びます。private readonly
このようにして、このフィールドのクラスを通常どおり単体テストできます。その後、統合テストで静的クラスをテストできます。
ちなみに、静的クラスに関する.NETの設計ガイドラインをご覧ください。質問に関連するものは何も含まれていませんが、貴重なアドバイスが含まれています。