タグ

DIコンテナに関するmimesisのブックマーク (5)

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

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

    Pimpleでシンプルに正しくDIを理解する
  • Symfony2のサービスコンテナについて - Qiita

    公式の解説 日語版 日語版記事には, Service Container (サービスコンテナ) (または 依存性注入コンテナ) はサービスのインスタンス化を管理する単純な PHP オブジェクトです。 と書かれています(最初は???でした). 要するに,サービス(PHPのクラスに対応するもの)をSymfony側に登録することにより,後で再利用できるようにするためのものらしいです. では,単純にクラスをnewでインスタンス化して使うのと何が違うのかというと,「依存性注入」によって,引数やその他の情報を設定ファイル上から定義できる点です. 依存性注入については,以下の記事がうまくまとまっていると思います. 猿でも分かる! Dependency Injection: 依存性の注入 ここで,依存性として注入できるのは,通常の引数だけでなく,設定ファイルのパラメータの値やリクエストオブジェクトやセ

    Symfony2のサービスコンテナについて - Qiita
  • 派遣労働者から見た、「まずはこう使え、DIコンテナ」

    IT業界の闇とは我々のことである お久しぶりです。もりすけと申します。 私はこのWebサービス業界に入ってこの方、 「SES(システムエンジニアリングサービス)」という形態で仕事を行っています。 我々にユニットテストのコストは計上されていない LaravelのDIコンテナはユニットテストと共に語られることが多く、 ユニットテストを回すという文化に触れる機会を逃していた私は、DIコンテナの有用性をしばらく理解できずにいました。 また理解する必要もないと思っていました。 ただ長いこと触れてみた結果、テスト抜きで考えても、DIコンテナにはそれなりのメリットがあると自分は考えています。 なので今回のテーマはこれです。 テスト抜きで考えて、DIコンテナの何がメリット足りうるのか そこを理解できればLaravelのDIコンテナを楽しく活用できるはずです。 前置きが長くなりましたが、ここからが題です。

    派遣労働者から見た、「まずはこう使え、DIコンテナ」
  • PHPでDI(Dependency Injection) - Qiita

    何かと話題のPHPでのDIについてまとめてみました。 そもそも DI(Dependency Injection)ってなんぞ? その名の通り、 依存性(Dependency)の 注入(Injection)です。 依存をクラス内で生成せずに外から設定します。 まだパッとしないので具体例を挙げて説明してみます。 まずDIでないパターン class Car { /** * @var EngineInterface */ private $engine; public function __construct() { $this->engine = new Engine(); } public function run() { $energy = $this->engine->burn(); } } このコードの良くない点 別のエンジンに変えたい時にCar.phpを修正しなければならない。 エンジン

    PHPでDI(Dependency Injection) - Qiita
  • DIコンテナの本当の使いどころ | ウルシステムズ株式会社

    DI の自由度は諸刃の剣 近ごろ、「実プロジェクトでDIコンテナ(注1)を導入している」という話をちらほら耳にするようになりました。それと同時に、「DIコンテナを使ったプロジェクトが大変なことになっている」という話も耳にするようになりました。DIの魅力を十分に享受して低コスト、高品質を実現しているプロジェクトがある一方で「DIを導入してみたのはいいのだけれど、DIの設定ファイルが大きくなりすぎて管理しきれない」「DIを使っているのに、テスタビリティが全然向上していない」など苦労しているプロジェクトもあるようです。この差はいったいどこから来るのでしょうか。 DIは、EJBなどと比べると比較的取っ付きやすい技術ではありますが、ほかの技術同様、誤った使い方では十分に力を発揮できません。DIコンテナは非常に単純明快な技術ではありますが、そのシンプルさ故に自由度が高くさまざまな使い方ができます。その

    DIコンテナの本当の使いどころ | ウルシステムズ株式会社
  • 1