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