2016-10-06 3 views
0

以下のシナリオを考えます。具体的なタイプのジェネリックインターフェイスを注入すると、依存関係注入の目的が無効になりますか?

public interface IRestaurant<IDinner, IDesert> { } 

public class Pasta : IDinner {} 
public class Cake : IDesert {} 

public class Chef 
{ 
    // resolving a mix of interfaces and concrete classes 
    public Chef(IRestaurant<Pasta, Cake>) { } 
} 

2つのコンクリートクラスの注入は、依存性注入の目的を無効にしますか?依存関係の注入がその結合を破るためにあるのに対し、私たちは現在PastaCakeのクラスに強く結合しているので、私の感覚はそうです。

次はもっと意味がありますか?

public class Chef<IDinner, IDesert> 
{ 
    public Chef(IRestaurant<IDinner, IDesert>) { } 
} 
+0

シェフがパスタやケーキ以外の夕食や砂糖を食べることはできますか? –

+0

最初の例では、いいえ、2番目の例ではyesです。 –

+0

シェフがそのコンビネーションだけを扱うことができるのであれば、具体的なタイプを使ってもうまくいくように思えます。彼らがそれよりも多くの組み合わせを扱うことができるなら、ジェネリックがより適切かもしれません。もしあなたが 'public class PastaAndCakeChef'と書いたのであれば、その意図はもっと明白でしょうか? –

答えて

1

私はあなたがDIは、本質的にあなたがインターフェイスまたはそれ自体が具体的なクラスを使用するかどうかは何の関係もありませんhere-概念を混合していると思います。パスタのいくつかのサブクラス(LinguiniRavioliなど)の1つだった具象クラスを注入することができ、DI(低結合、離散テスト容易性)の利点が依然として適用されます。

ほとんどの人は、実装を暗示することなく、必要な特定のインターフェイスへの結合をさらに低下させるため、インターフェイスを使用します(たとえば、Pastaから継承することは意味がありません)。 IoCの懸念。

+1

たとえクラスがなくても、依存関係注入は純粋に機能的な言語でさえ適用されると主張することができる。 DIとは、実装の選択肢を契約(用途)から切り離すだけです。独立したテストのために設計された実装を構築するインセンティブが得られたらと思います。 –

+0

インタフェース/継承のないDependency Injectionは、従属クラスの外部から依存関係のコンストラクタの引数を変更することができます。インタフェース/継承では、依存関係の実装をクラス外から変更することもできます。そうですか? (私の前のコメントを削除するためのお詫び)。 –

+1

心配はいりません。私はあなたが何を求めているのかはっきりしていませんが、一般的なDIパターン(少なくともJava/C#では)はコンストラクタに渡されるものが*必須の依存関係であり、プロパティとして設定されたもの)はオプションの依存関係です(設定することはできますが、クラスはそれを使わずに作業を行うことができます)。また、DIに固有のものではなく、通常のコードで使用する実装を変更することもできますが、DIは標準的で一貫性のある方法を提供します。 –

関連する問題