DI って何でするのかわからない人向けに頑張って説明してみる「本来の意味」 - Qiita

クラス図にするとこんな感じですね。 (メソッドは省略) こんな風に上位のクラス（Presentation）が、より下位のクラス (Application) に依存していると上位のクラスの再利用が妨げられます。SomeApplication をがっちりつかんでて使いまわししづらいです。芋づる式に上位のクラスを使おうと思うと下位のクラスにがついてきます。 依存性の逆転 実装に直接依存するのではなく、間に抽象を挟むことで実装に依存しなくなります。 ISomeApplication は、SomePresentation の都合によって定義されるもので SomePresentation の一部だと考えると SomeApplication から Presentation 側に矢印が向いてる感じになってるように見えますね。矢印の向きが反対になりました。 組み立てないと… こういう風に定義すると、やっぱり

[j5ik2o]

"DIPを実現するのにDIコンテナが必須か"は議論が分かれるところ。十分に分散統治されたファトリでもよいのでは？とか。ScalaならDIコンテナなしでDIできる。DIコンテナを使う理由にはAOPや依存F/Wを利用するためなどもある

[hdampty7]

そうじゃないんだよなぁ。頑張ってみたけど、100文字で説明するのは無理ぽ。AOPとか期待しないなら基本factoryパターンでだいたいOK。factoryだとこういう問題があるなぁと気が付いたときにDIが待っている。

[n314]

単体テストのための設計だとそうなるかもしれないけど、これ逆転してなくない？逆転だとISomePresentationになるような。

[rryu]

DIはテスト用に元のオブジェクトと挙動に互換性がありつつテストに都合が良い実装を別系統で用意するの大変すぎない？と思ったところからが本番だと思う。

[kwhrtsk]

UI周辺で多いけど、(1)依存関係が頻繁に変更される(2)依存関係が複雑(3)依存の記述量が多い、というような場合にはDIコンテナを使うと楽になる事はある。そうでなければDI/factoryで十分だし、テスタビリティには大差ない。

[lalupin4]

数年に一度挑戦するが逆に依存関係を見失って投げ出してる。毎回ブコメのように Factory というか Service Locator でよかったやんてなる。

[hara_boon]

コードブロックで引用はワロタ

[sho]

コードブロックで引用するのをやめろ

[dagjmpd]

チッチキチッチー