Pimpleでシンプルに正しくDIを理解する

オブジェクト指向でソフトウェアを実装していると、オブジェクトの生成に一連の手続きが必要なものがでてきます。このような生成に関する手続きがあちこちのソースコードへ散在すると、望ましくない状況になることは想像に難くないでしょう。この問題に対処するために、Simple FactoryやFactory Methodといったデザインパターンがあり、オブジェクトの生成に関する手続きや関連オブジェクトも含めたオブジェクトの構成（オブジェクトコンストラクション）に関する知識は1箇所にまとめるということが定石となっています。 しかし、単にファクトリーを導入するだけだと、オブジェクトの構成処理は分離・隠蔽できても、利用オブジェクトがファクトリー自体に依存してしまうことになります。このような試行錯誤の歴史から登場したのがDependency Injection(依存性の注入)パターンです。Dependency

[somemo]

“その1で紹介したコードは、サービスロケーターとしてDIコンテナを使っています。サービスロケーターがDIより劣っているということではありません。それぞれ適材適所で使い分けていくものです。"

[naka-06_18]

DI と Service Locator

[kohkimakimoto]

メモ：オブジェクトからコンテナにアクセス（依存）しないようにする。

[zuborawka]

DIの説明。アンチパターンとの比較があるのでわかり易い。完全には理解できてないけど、過去に読んだ記事の中ではよく分かるような気がする。DIを理解したあとで過去の自分のコードを見返すには勇気がいるだろうな。

[calpo]

サービスロケーター DI

[oppara]

PHPメンターズ -> Pimpleでシンプルに正しくDIを理解する

[t-wada]

PHP で Pimple を使って DI(Dependency Injection) を行う方法と、そのメリットの説明。きちんと書かれている。

[PaulYamamoto]

やっぱりPHPでもDIコンテナは便利だなぁ。　CodeIgniterは作りが古いから余計に便利そうに感じるなぁ。

[noopable]

"サービスロケーターがDIより劣っているということではありません。それぞれ適材適所で使い分けていくものです。"

[brtRiver]

"オブジェクトの構成処理は分離・隠蔽できても、利用オブジェクトがファクトリー自体に依存してしまうことになります" あいたたた。

[hiro_y]

PimpleでDIコンテナを