「なぜDI(依存性注入)が必要なのか？」についてGoogleが解説しているページを翻訳した - Qiita

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

[t-wada]

テスト容易性が引き合いに出されるけどメリットはそれだけでなく、DIとDIコンテナの導入で中間層を挟む余地がいたる所に生まれ、変更に強く中長期的にリカバリの効くアーキテクチャ基盤を作れるのがありがたい

[wyukawa]

Seasar2が出てきた頃にこういう議論があった気がする。DI単体だとテストしやすいぐらいのメリットしかないけどAOPと組み合わせるとボイラープレートコードが無くなるよって話だったような。

[HHR]

確かに「なぜDI(依存性注入)が必要なのか？」に対して明確に回答してない… たぶん疎結合にしてテストしやすくかな。 やっぱり依存性注入と訳すとモニョる。依存オブジェクト注入デザインパターンの一つだと長いし…

[yoshikogahaku]

“依存性注入”って日本語を聞く度にヤバイお薬のことしか連想できない。もうフワフワになってお茶碗取ろうとしても直前で別のもん掴んだりログ吐いたりしちゃうんよ。

[shoma]

交換しやすさのために疎結合にするのと、Testable にするのがメインの目的といっていい気もする

[ledsun]

「Javaでは動的に振る舞いを変える手段がないので他に選択肢が無い」で良いのでは？静的型付け言語（JavaやC#）でプラグイン機構作るならDI一択。/「テスト容易性」は規模が大きく無いとペイしなさそう。

[rryu]

「dependency」を「依存性」と訳してしまったのが理解しにくさの原因な気がする。「従属物」とかなら分りやすいのに。

[daimatz]

どちらにしろ Guice の Wiki はよくまとまっているので一通り読んどくと捗る

[katzchang]

Guiceとかの「DIコンテナを使うと簡単になる」っていう主張、あんまり賛同できないんだよなー（DIパターンは基本中の基本）

[ktanaka117]

あとよみ

[watarum]

これやか[interface]

[t1mvverr]

スタブじゃだめなのだろうか

[bc_rikko]

依存性をどう解決すべきか

[koriym]

Guice != DI"コンテナ"

[reitanigawa]

テストまで考えないとDIの意味がないね。

[zilog80]

多分読まない

[Jxck]

DI のメリットの良い解説

[nyop]

依存性の管理の方法次第だけど、テストの簡素化だけじゃなくて依存性を外部化することで、そのコード自体の保守性や汎用性を高める余地があることが価値なんではないかと。

[hironei]

この話がわかる技術者が社内に少ない、、、、

[kasumani]

「なぜDI(依存性注入)が必要なのか？」についてGoogleが解説しているページを翻訳した　 イマイチ理解しきれていなかったDIに関して調べていところ、Google Guiceの解説がすごく分かりやすかったので、和訳してみました。 （

[kaipu1224]

DeepImpact

[civitaspo]

Guice、Embulk 本体のコードでもよく見かける http://ift.tt/2bqkKjX

[eller]

自分の中では、クライアントのテスト可能性向上（受動的な依存先決定を行うための便利基盤） ＞＞ サービスのライフサイクル管理 ＞ 依存先を実行時に決定（プラグイン機構など）かな。

[taguch1]

nodeだとrequireproxyとかでテスト自体はなんとかなる気もするけど、babelとこで混ざるとめんどい。結果DIコンテナは便利でした。

[kabacsharp]

“Guiceはアノテーションのついたコンストラクタを調べ、引数の値を見つけてきてくれます。”なるほど。

[lmhh]

“Guice”

[mmpppp39]

、

[raitu]

「Factoryのように、DIもデザインパターンです。その基本的な考え方は、 振るまいと依存性解決を分離する ことです」これによってテストの修正を容易にするらしい

[hogege]

φ(･_･

[matsnow]

確かにわかりやすい。scalaでプログラミングするなら使いたい。