2012-02-14 8 views
3

私は、次のシナリオが依存性注入の良いユースケースであるかどうかを知ることに興味があります。この例は少し構成されていて、良いOO設計ではないかもしれません。私と一緒にクマとの質問に関連する部分に焦点を当ててください:依存性注入 - 実行時の引数の決定

はのは、私は以下のクラスがあるとしましょう:

class BankAccount 
{ 
    User user; 
    Integer accountNo; 

    BankAccount(User user, Integer accountNo){ 
     .... 
    } 
} 

class User 
{ 
    String firstName, lastName; 

    User(String firstName, String lastName) 
    { 
     .... 
    } 
} 

はのは、私は次のシナリオでオブジェクトを作成するとしましょう:

void withoutDependecyInjectionUsingNewOperator() 
{ 
    User user = new User("Lance", "Armstrong"); 
    // These values are determined 
    // based on form input on UI 
    BankAccount account = new BankAccount(user, 1233); 
} 

DIをサポートするGuiceやSpringのようなフレームワークについて知りました。 これらのフレームワークを使用していた場合は、上記の機能を変更する必要があります DIを使用しますか?

私はチュートリアルでは、これまで見てきた例に基づいて、コンストラクタの引数が 値が最終的にユーザ入力に基づいている場合のための構成として決定していないことができたとき、それは ほとんどが便利であると思われますか?

ありがとうございます!

+0

関連:http://stackoverflow.com/questions/4835046/why-not-use-an-ioc-container-to-resolve-dependencies-for-entities-business-objec/4836790#4836790 –

答えて

1

あなたが投稿した内容に基づいて、それは依存性注入の適切な使用ではありません。それは工場のパターンのためのまともなケースです。 Dependency Injectionは、インターフェイスを使用し、実行時に具体的な型のみを設定することによって特定の型への依存を排除​​するために使用されます(通常は、ninjectのようなサードパーティフレームワークを使用します)。

たとえば、BankAccount型が使用するIUserFactory IUsersを取得する。実行時に、BankAccountクラスは、コンパイル時に依存するのではなく、具体的なUserFactoryクラスを「注入」することができます。その後、BankAccountクラスを必要とせずにUserFactoriesを交換することができます。