Design patterns => 依存性注入

前書き

Dependency Injectionの背後にある一般的な考え方は、依存関係の反転原理を遵守しながら、疎結合コンポーネントの周りにアプリケーションを設計することです。具体的な実装に依存しないため、非常に柔軟なシステムを設計することができます。

備考

依存性注入の背後にある基本的な考え方は、より疎結合のコードを作成することです。クラスが独自の依存関係を新しく作成するのではなく、その依存関係を取り入れる場合、クラスはユニットとしてテストするのがより簡単になります（単体テスト）。

さらに緩やかな結合について詳しく説明するために、クラスは、凝結よりも抽象に依存するようになっています。クラスAが別の具象クラスB依存する場合、 BなしのAの実際のテストは存在しません。この種のテストはOKですが、単体テスト可能なコードには向いていません。疎結合設計は、クラスAが依存する抽象化IB （一例として）を定義する。 IBは、 Aテスト可能なシナリオを提供できるように、 Bの実際の実装に頼るのではなく、テスト可能な動作を提供するために嘲笑されます。

密接に結合された例（C＃）：

public class A
{
    public void DoStuff()
    {
        B b = new B();
        b.Foo();
    }
}

上記において、クラスAはB依存する。コンクリートBないテストAはありません。これは統合テストのシナリオでは問題ありませんが、テストAを単体テストすることは困難です。

上記のより疎結合された実装は次のようになります。

public interface IB
{
    void Foo();
}

public class A
{
    private readonly IB _iB;

    public A(IB iB)
    {
        _iB = iB;
    }

    public void DoStuff()
    {
        _b.Foo();
    }
}

2つの実装は全く同じように見えますが、重要な違いがあります。クラスAはもはやクラスB直接依存していないが、現在はIB依存している。クラスAはもはや独自の嫌悪感を新しくする責任を負いません。彼らは今、 Aに提供されなければなりません。

セッター注入（C＃）

public class Foo
{
    private IBar _iBar;
    public IBar iBar { set { _iBar = value; } }

    public void DoStuff()
    {
        _iBar.DoSomething();
    }
}

public interface IBar
{
    void DoSomething();
}

コンストラクタインジェクション（C＃）

public class Foo
{
    private readonly IBar _iBar;

    public Foo(IBar iBar)
    {
        _iBar = iBar;
    }

    public void DoStuff()
    {
        _bar.DoSomething();
    }
}

public interface IBar
{
    void DoSomething();
}

Modified text is an extract of the original Stack Overflow Documentation

ライセンスを受けた CC BY-SA 3.0

所属していない Stack Overflow

Design patterns
依存性注入

サーチ…

前書き

備考

セッター注入（C＃）

コンストラクタインジェクション（C＃）