タグ

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

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

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

    DI・DIコンテナ、ちゃんと理解出来てる・・? - Qiita
  • 作って理解するDIコンテナ - きしだのHatena

    DIコンテナ使ってるけど、アノテーションってなんなの!って聞かれて、作ってみたらわかるよと答えてみたので、自分でも作ってみました。 よくわかった。 「DIコンテナ使うと何がいいの?」ということも、作ってみるとわかります。あと「DIって何がいいの?」に関しては、「DIはちょっとコードを書くのが楽になるだけで、それだけあっても仕方ない、大事なのはコンテナ」と答えるようにしてますが、コード比率からもそれがよくわかります。 続編としてWebフレームワークも作っているので参考まで。 作って理解するWebフレームワーク - きしだのHatena まずはコンテナを作る とりあえず1ソースの状態で。 こんな感じで、管理する型を登録できるようにします。 static Map<String, Class> types = new HashMap<>(); static void register(String

    作って理解するDIコンテナ - きしだのHatena
  • DIについてあれこれ - tototoshi の日記

    Dependency Injectionとはコンポーネント間の依存関係をプログラムのソースコードから排除し、外部の設定ファイルなどで注入できるようにするソフトウェアパターンである ってwikipedia先生が言ってました。 Scalaにおける最適なDependency Injectionの方法を考察する 〜なぜドワンゴアカウントシステムの生産性は高いのか〜 - Qiita を読んでいろいろ考えたので、なんで今さらって感じのことを書きます。 ScalaでDIというとDIコンテナとかCake PatternとかReader Monadとかって話になっちゃうんですが、これらはいかにかっこよくDIするかの話であって、別にこういった道具やパターンを使わなくてもDIは可能という話です。 Constructor Injection 簡単な例で考えます。今ここにUserRepositoryにべったり依存し

    DIについてあれこれ - tototoshi の日記
  • PHP製DIコンテナ"yadif"をZend_Applicationと共に使う - noopな日々

    Zend_Applicationはフレームワークの設定と主要インスタンスの管理に使いますが、今のところモデル用のリソースがありません。 PHP製のシンプルなDIコンテナ"yadif"は設定によるオブジェクトの生成と管理が可能で、モデルの管理にも適します。ここでは、yadifを利用してサービスリソースを作成し、アプリケーションからモデルにシンボル名でアクセスできるようにします。 Zend_Applicationでのリソースの作成その他については、公式マニュアルに十分な解説がありますが、こちら(Zend_Application (5) 実戦的使い方 - noopな日々)でも書きました。 Yadif - Yet Another Dependency Injection Framework を使う GitHub - tsmckelvey/yadif: Yet Another (PHP) Depen

    PHP製DIコンテナ"yadif"をZend_Applicationと共に使う - noopな日々
  • Pimpleでシンプルに正しくDIを理解する

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

    Pimpleでシンプルに正しくDIを理解する
  • 最小のDIコンテナ in PHP - id:anatooのブログ

    DIコンテナがなにやら大仰なものとして勘違いされているような気がしたので、機能を極限まで削ぎ落とした最小のDIコンテナを書いた。 これにはAOPは当然ないし、設定ファイルなどもない。 <?php // DIContainer.php class DIContainer { protected $componentFactory; function __construct(ComponentFactory $c) { $this->componentFactory = $c; $c->accept($this); } function get($name) { $name = strtolower($name); if (!isset($this->objects[$name])) { $this->objects[$name] = $this->componentFactory->get(

    最小のDIコンテナ in PHP - id:anatooのブログ
  • 1