DI・DIコンテナ、ちゃんと理解出来てる・・？ - Qiita

意外と分からずに、「とりあえず」とか「なんとなく」で使っちゃうパターンが多い系案件な気がして書いてみます。 こんな事ありませんか？ DIとDIコンテナの違いを説明出来ない DIとサービスロケータの違いを説明出来ない DIを使ってるつもりが、サービスロケータになっている DI、サービスロケータが、ただの「パターン」の１つであることを理解してない DI(Dependency Injection)を正しく理解する そもそも、Dependeny Injectionを日本語にするとどういう意味になるでしょうか。 多くの人が「依存性の注入」とか応えるのではないでしょうか？ 私もそうでした。きっと何かで読んだのでしょう。 (wikipediaに「依存性の注入」と書いてありますね) 補足 なぜ依存性を注入してあげると良いのか、そのメリット等は後述しますが、 DIというのはただのパターンの１つです。 たまに

[vanbraam]

最初の例で,元のコードはLoggerに内部的に依存しているが,その依存関係をconstructor引数を使って外部化し,依存先で依存性を定義可能にするのがDIなのだから,"依存性の注入"で合ってる.寧ろobjectと言い換える方が意味不明

[diffie]

http://blog.a-way-out.net/blog/2015/08/31/your-dependency-injection-is-wrong-as-I-expected/ と同じひと? パクリ? オマージュ?

[shimooka]

DIコンテナ使う時のキー("database.authenticator"とか"file.loggger")って知らなきゃ使えないが、個人的にはこれらを調べたり覚えるコストが意外に高い。なので、DI系フレームワークをいじるのは食傷気味。。。

[gt-r-blaze]

Springだとアノテーションで書くからプリプロセッサの一種みたいなのと思ってたけど違った。A dependency is an object that can be used (a service).=「Dependency」(依存性と訳していた)は、「オブジェクト」です。

[ten-gallon-Mouse]

“「Dependency」(依存性と訳していた)は、「オブジェクト」です。つまり、DIとは、「依存性の注入」じゃなくて、「オブジェクトの注入」だった訳ですね。”

[naoyuki1019]

php デザインパターン

[ghostbass]

object that can be used を単純に object にしてしまうのは良くない。「利用可能なオブジェクト」の構築(construct)を利用者から隠蔽するのが目的なのでは。

[animist]

この解説はわかりやすかった。アンチパターンも入れてもらえるとそういう事かってなる

[tettekete37564]

非常にわかりやすい。んだけどやはりDIのメリットに納得しかねる。< DIコンテナを正しくセットアップする仕様がコードから読めない。途中で挙げられたDIじゃない場合のデメリットが結局DIコンテナに発生している希ガス

[torinky]

DI・DIコンテナ、ちゃんと理解出来てる・・？

[civitaspo]

http://ift.tt/2b4djL0

[eerga]

導入部分は興味を引かれたけど、内容は期待はずれだった。パターン言語を学びましょう。

[goro56goro5656]

あとで読む

[gologo13]

DI Container と Service Locator は区別出来てなかったので学びあった。

[stealthinu]

DIの話をPHPでやってくれてるところがよい。DIと言えばJavaばかりだから。

[nunux]

DI DIコンテナ

[hatsu_mi]

わかりやすい

[Jxck]

"サービスロケータパターン"

[efcl]

DIとDIコンテナとサービスロケータについて

[k-holy]

DIの導入目的を考えると依存をクラスの内部コードに隠蔽してしまうサービスロケータは間違いなく悪。Laravelのファサードは実質サービスロケータだから嫌い。Phalconも同様だし分かっててそう設計してるんだろうけど…

[n314]

$container['sample'] この配列参照が関数呼び出しになるのか…。大した手間ではないんだから $container->get('sample') の方が分かりやすいような。