1

つまり、クラスA、B、Cがあるとします。クラスAには単一責任がありますが、クラスBとCの機能が必要なので、最初はAにBとCから継承させたいと考え、次に「継承に対する構成」に従って実現しました。原則として、AIのBおよびCメンバーを作成すると、設計の剛性が低下し、これら2つのクラスがより再利用可能になる可能性があります。

最初はBとCをAのコンストラクターでインスタンス化するだけで済みましたが、最終的には他の2つまたは3つの場所で呼び出す必要のあるメソッドがありました。他の場所でクラスを再利用していたため、適切な場所で多くの不要な欠陥が発生し、時間が無駄になります...私の質問は、依存性注入がこの問題に役立つのか、構成の使用の複雑さを軽減するのに役立つのか、もしそうならどのように役立つのかということです。

public class A
{
     private mB;
     private mC;
     public A(IB b, IC c)
     {
         mB = b;
         mC = c;
     }
     public MethodX()
     {
         mB.DoWhatever();
     }
     public MethodY()
     {
         mC.DoSomething();
     }
}

私が理解していることから、DIを使用すると、IBとICの具体的なクラスをこのようなコンストラクターに通してその作成を処理することができますが、他にどのように役立ちますか（複雑さに関して）？

私はこの記事を理解していないことに基づいてこの質問をすることにしました：http：//lostechies.com/chadmyers/2010/02/13/composition-versus-inheritance/

実際の例として、StateがBeginメソッドを呼び出すときにイベントを登録し、Endメソッドを呼び出すときに登録を解除する必要があるEventListenerクラスを含むStateクラスがあるとします。

4

4 に答える 4

3

依存性注入は、オブジェクトの構成をまったく支援しません。インジェクションを使用する前に、ある程度の構成可能性が必要です。一般に、依存性逆転は、従来の依存関係を逆転させるために使用されます。これにより、依存関係を抽象化によってモデル化でき、それ自体を直接結合せずに他の何かに注入できます。インジェクションは、合成ではなく、デカップリングを支援する反転の形式です。

于 2012-08-14T03:19:34.273 に答える
1

あなたの推論は健全であり、あなたは正しい方向に進んでいます。

インターフェイス/抽象化を介したDIと構成の使用により、ボットはコードのtstと構築を容易にします。プロセスに役立つ場合は、Aの構築中にBとCの一時的な「偽の」実装を使用できます。

一般的な解決策は、A、B、およびCの構造と構成をファクトリクラスまたはAのサブクラスに分解することです。

于 2012-08-14T08:52:15.197 に答える
0

依存性注入は、依存性の作成を自動化および管理することにより、依存性を処理する際の複雑さをある程度相殺します。（AutofacやUnityなどのIOCコンテナを使用して実装した場合）A、B、およびCの単純な例では、実際の節約を確認するのはおそらくかなり困難です。複雑さが低下し始めたのは、Cに依存するクラスDを実装したときです。DIを容易にするIOCコンテナーは、A、B、およびCを（AとBを使用して）構成する方法を知っているので、手で転がします。コードは、依存関係として渡すオブジェクトのインスタンスの作成について心配する必要はありません。複雑さによって、依存関係を管理するために必要なコード/ベビーシッターの量を指します。

Peterが指摘しているように、IOCとDIが本当に優れているのは、依存関係を相互に分離して、コードを分離してテストできるようにすることです。クラスCの単体テストを作成したいが、CがAとBのインスタンスを作成する場合、AとBから分離してテストすることはできません。AまたはBがデータサービスやファイルサービスのようなものである場合、単体テストを行うことができます。痛い。Cは、IOCを利用して、モックアウトできるサービスのコントラクトインターフェイスへの参照を受け入れます。このようにして、Cはその依存関係から予測可能な動作でテストできます。

于 2012-08-14T05:46:58.743 に答える
0

DIについてのあなたの理解は正しいと思います。クラスAからクラスBとCのインスタンス化を削除することにより、DIはそれらの相互結合を少なくします。現在、クラスAは、具体的な実装ではなく、抽象インターフェイスIBおよびICに依存しています。これにより、クラスAのコードがより柔軟になり（必要に応じて、DIコンテナーを再構成するだけで、必要に応じてIBおよびICの他の実装を簡単に挿入できます）、テスト可能になります（IBおよびICのモック実装を挿入できます）。また、これにより、クラスAのコードが読みやすくなります。これは、コラボレーターIBおよびICへの依存関係が、コンストラクターの署名によって明示的に示されるためです。

于 2012-08-14T03:17:02.827 に答える