web-dev-qa-db-ja.com

クラスが1回だけ使用されている場合でも、依存性注入を使用する必要がありますか？

コードのレビュー中に、依存関係の注入を使用するかどうかについて、少しジレンマを抱え始めました。これは進行中のテーマの一種であり、将来のコードレビューにも役立つので、ご意見をお聞かせください。

始める前に、私の知る限り、DIは主に依存関係の管理と、より優れた、はるかに簡単な単体テストに使用されていると言いたいです（間違っている場合は修正してください）。

これがシナリオです：

これは、依存関係として1回だけ使用されるクラスです。つまり、しばらくの間その状態が続き、他のクラスはそれを使用しません。

理由は、それがいくつかのレガシーコードのリファクタリングであり、少なくとも最初の適切なステップとして [〜＃〜] srp [ 〜＃〜] 。

また、もう1つは、架空のdoSomethingImportant（）がデータベースにヒットすることです。

public SomeClass
{
   public Object doSomethingImportant()
   {
      ...
   }
}

その情報に基づいて、DIを使用するのではなく、他のクラスの依存関係を新しくしても大丈夫だと思いますか？

依存性管理引数は、一度しか使用されないため、低下します。

＆

統合テストまたは受け入れテストを行って、実際のアプリケーションでメソッドがデータベースとどのように相互作用しているかを確認したいので、ユニットテストも落ちています。

public SomeOtherClass
{
   private readonly SomeClass _someClass = new SomeClass();

   public Object doSomethingImportantUsingDependency()
   {
      ...
   }
}

私は個人的にDIを好む傾向があるため、DIを行う傾向がありましたが、一瞬、規則には例外があり、盲目的に規則を順守しているのではないかと感じました。

これについてどう思いますか？聞きたいです。

PS：これは一般的な「いつDIを使用すべきか」という質問ではないと思います。ユニットテストが役に立たず、クラスが依存関係の管理のために一元化する必要がないので、1回だけ使用します（一般的には良い習慣ですが）。

c#.netunit-testingdependency-injectiondependency-management
15
AvetisG

C＃では、依存関係にあまり強く結合せずに、オプションの依存関係注入を提供するのは簡単です。

public class SomeOtherClass {
    private readonly ISomeClass _someClass;

    public SomeOtherClass(ISomeClass dependency = null) {
        _someClass = dependency ?? new SomeClass();
    }
}

（または、会社がデフォルトのパラメーターを嫌う場合は、コンストラクターを明示的にすることができます）

私の経験では、「ああ、もう1つ必要になることはない」というのは初心者です。ビジネスの変化。テクノロジーの変化。依存関係を柔軟にします。

そして、この種のものは、使いやすさ（そうです、ほとんどの場合、共通/デフォルトのものを使用します）と柔軟性（しかし、必要な場合にはctorが存在します）の適切なバランスを取ります。エラー訂正の堅牢性の類似性も提供します。これは非常に簡単で、明らかに有益です。単純な/まっすぐな場合にそれをしない理由はありません。

15
Telastyn

DRYおよびSOLID YAGNIと呼ばれる）の方針に沿った開発原則があります。これは、物事を成し遂げ、決断力が麻痺しないようにするための開発努力を合理化するのに役立つように設計されています何をすべきかについて。

後でクラスを強化する必要があることがわかった場合は、強化します。 YAGNIは、今ではそれほど心配する必要はないと述べています。それをやり遂げ、本当に必要なら戻ってきてください。

SOLIDの反対ですが、開発に関連するすべての要素をトレードオフすることがすべてであり、無限の時間やリソースはありません（「完璧な」コードは決してIMHOではありません）。

したがって、ここでは、DIの複雑さは必要ないと言っているので、答えがあります。それを入れないでください。あなたがしなければならない他のすべてのものに進みます。

11
gbjbaanb

DIを実際に必要としない限り（単体テストの場合でも）DIを適用しない場合、問題は発生しません。コードはエラーが発生しやすくなったり、「過度に複雑」になったり、保守が困難になったりしません。そして、依存関係を後でリファクタリングすることを決定した場合、おそらく今それを行うよりもはるかに多くの努力ではありません。これは、YAGNIの原則が適用される場合です。

ただし、SomeOtherClassから分離して単体テストSomeClassを本当に実行したくないことが確かであるかどうか、およびSomeOtherClassおよびSomeClass liveは問題になりません。前の質問に対する答えが「はい」であると100％確信している場合は、DIを無視できます。

5
Doc Brown

ほとんどの場合のように答えは「それは依存する」です。

doSomethingImportantUsingDependencyの機能を単体テストする場合は、依存関係を注入できる必要があります。

ただし、doSomethingImportantUsingDependencyがデータベース呼び出しの結果からのプロパティマッピングのみを行う場合は、煩わしくないのが実用的です。

他のクラスがSomeOtherClassに依存している場合は、代わりにそのクラスをいつでも注入できます。

0
Matthew