タグ

PHPとDIに関するarray08_12のブックマーク (6)

  • Pinocoでシンプルに正しく(&ぶっちゃけで)DIを理解する - なんたらノート第三期ベータ

    Pinocoだって実はすごいんだぞ、Pimpleになんて負けないもん、というわけで、 PHPメンターズ -> Pimpleでシンプルに正しくDIを理解する をPinocoで理解してみようというネタをやります。先にこれを見ておいてください。 あ、「Pinocoってなんやねん、あっちょんぶりけかよ」って思った人すみません。Pinocoは拙作のマイクロフレームワークです。いわゆるオレオレの一種ですが、オレオレにしてはかなりよくできたほうだと思います。RESTなAPIを作る他のと比べて、どっちかといえばWebサイトを作るほうが強い感じのヤツ。 https://github.com/tanakahisateru/pinoco で、DIですよ。依存性注入ですよ。楽しんご的なアレじゃないですよ。オブジェクト指向ですよ。 Pinocoの第一印象はみんな「プレーンPHPっぽいね」で、それはそれで狙い通りなん

    Pinocoでシンプルに正しく(&ぶっちゃけで)DIを理解する - なんたらノート第三期ベータ
  • PHPのDIで動的にオブジェクトを確保する考察

    Dependency InjectionがPHPでも流行っているそうです。が、未だによくわからないので、わからないところを自分なりに考察してみます。 ※DIコンテナではなくデザインパターンとしてのDIを考えます。 Dependency Injectionとは Dependency Injectionはデザインパターンの一種です。日語なら依存性の注入と訳されます。「Inversion of Control コンテナと Dependency Injection パターン」が原典でしょうか。 ざっくり要約すると「クラスの中でnewしてはいけない。必要なインスタンスは外から突っ込むべし」というところかな。 class Y { private $x; function __construct() { $this->x = new X; } //...$xを使ったコード色々... } 上記のYクラス

    PHPのDIで動的にオブジェクトを確保する考察
  • Zend\Diを使ったDIの自動ワイヤリング

    「Pimpleでシンプルに正しくDIを理解する」の記事では、シンプルなDIコンテナPimpleにオブジェクトの依存関係の知識を集約する方法について解説しました。Pimpleの場合はサービスオブジェクトのファクトリーとして機能する無名関数の中に依存オブジェクトを記述しました。このように、実際に利用する依存オブジェクトを決めることをワイヤリングと呼びます。 今回は、ほぼ同一のオブジェクトモデルに対して、Zend Framework 2.0のDIライブラリ(Zend\Di)を使うように置き換えてみます。一般的にDIを扱う場合、依存関係の定義とワイヤリングのために何らかのコード―これは何らかの設定言語だったりプログラミング言語だったりします―を記述しなければならず、ある程度の規模以上のモデルクラス群をDIコンテナで管理する場合、定義のコーディング量がばかにならくなってきます。しかし、型を持ったプロ

    Zend\Diを使ったDIの自動ワイヤリング
  • Pieceの中のSymfony #3: Dependency Injectionコンポーネント

    Piece FrameworkのプロダクトのひとつStagehand_TestRunnerは、CLIでユニットテストを実行するための継続的テストランナーです。Stagehand_TestRunner v3の実装には多くのSymfonyコンポーネントが使われています。今回はStagehand_TestRunnerを動作させる上で重要な役割を果たしているDependency Injectionコンポーネントについて具体的な使い方を解説します。 Symfony Dependency InjectionコンポーネントDependency InjectionコンポーネントはSymfonyにおけるDIコンテナの実装であり、WebアプリケーションフレームワークとしてのSymfonyの基盤となるプロダクトです。サービスの依存性とその注入方法の定義、サービスの作成・取得、サービスへの依存性の注入、といったD

    Pieceの中のSymfony #3: Dependency Injectionコンポーネント
  • Pimpleでシンプルに正しくDIを理解する

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

    Pimpleでシンプルに正しくDIを理解する
  • » Learning About Dependency Injection and PHP Ralph Schindler

    Over the past few years, there are a few concepts and programming patterns that have muscled their way into the hearts and minds of PHP developers from other languages and programming communities. These concepts range from the MVC application architecture as well as various modeling techniques (think ActiveRecord and Data Mapper), to a pure shift in the way we think about application architectures

  • 1