2017-05-19 5 views
0

私は依存性注入が何であるか理解していますが、それでも消費者にとってどのように役立つかという点でまだ完全な画像は見ていません。以下の例を参照してください。依存性注入フレームワーク - 依存性伝播

//bad 
class car() { 
    var tire = new Tire('snow'); 
} 

//good 
class car() { 
    var tire; 
    constructor(tire){ 
    this.tire=tire 
    } 
} 

だから、ほとんどの記事は、私はそれが車からタイヤの依存関係を解消し、よりテスト可能となるので、上記の例が良好であることの状態を読みました。しかし、車オブジェクトをインスタンス化する他のクラスはどうでしょうか。 driverクラスがcarクラスを呼び出すのであれば、ドライバはcarオブジェクトとtiresもインスタンス化するように強制しません。それは依存関係が常により深く伝播していくかのようです。これはどこですか?オブジェクトを実際にインスタンス化するのは何ですか?これは、DIフレームワークはすべてについてですか?

+1

一言で言えば:はい、それはずっと進んでいますし、それが単純化するためのDIフレームワークです。 – deceze

答えて

1

依存関係の要件がすべて「伝播」されることは間違いありません。車をインスタンス化したいと思う運転者はCarTireを持って来なければなりません。ドライバが多いドライバプールでは、DriverCarTireなどが必要です。それに対抗するための簡単な方法は、工場出荷時に物事をバンドルされています

class Driver { 
    constructor(carFactory) { 
     this.car = carFactory.newCarWithRegularTires(); 
    } 
} 

(例示の目的のみのために、以下を参照してください。)

をあなたが他の車を作成することができます別の工場を注入し、することができますCarの依存関係は、Driverがこれを意識する必要なく変更できます。

さらに進んで、あらゆる種類のオブジェクトを作成できる一般的なグローバルファクトリを作成し、依存性注入コンテナであるそれぞれの依存関係をどのように満たすかを知ることができます。通常は、テキスト形式で構成します。が必要です。Carのインスタンスを要求すると、最初にTireをインスタンス化して渡します。

DIコンテナの欠点は、DIコンテナを再設定するだけで依然として依存関係をスワップできますが、場合によっては全体を再構成する必要があり、巨大な独立したオブジェクトレジストリになるということです。 1つの巨大なコンテナを作成することは避けてください。

工場の別の言葉:上記の工場の例はあまり良くありません。実行時にオブジェクトの新しいインスタンスを作成する必要がある場合、オブジェクトはファクトリを使用する必要があります。 ではなく、は単に直接注入できる依存関係を満たすために工場を使用する必要があります。

最終的に、依存関係を直接宣言して受け取るクラス間のバランスを取りたいだけでなく、非常に深い依存関係階層を作成しないことも必要です。依存関係を可能な限り浅く保つことは良いスタートです。工場やモジュラーDIコンテナの導入は別の方法です。

+0

素晴らしい答え。私の理解を確認するために、オブジェクトをインスタンス化することは避けられないと言っています。依存関係の階層を可能な限りシンプルかつシンプルに保ち、必要に応じてファクトリを使用することです。あなたは、そうするときにあなたを導く通常の規則をお持ちですか? – alaboudi

+1

"苦痛になってから、ステップバックとリファクタリングが始まります。DIコンテナ/工場は、グラフを再び狭くするだけでなく、より多くのバンドリングを導入し、やや難しくなります。それが適していると思われる場合は、それらのグラフの戦略的スポット – deceze