DI コンテナがコードに出現するのは dependency lookup が行われている兆候
Dependency Injection (DI) コンテナを基盤にしたアーキテクチャを採用している場合に、(プロダクト|テスト)コードに DI コンテナが登場するのは dependency lookup (依存コンポーネントの検索)を行っている兆候と考えることが出来ます(もちろん必要があってコンテナの injection が行われている場合もあります)。 テストに DI コンテナが出現することに気付いたら、 Dependency lookup から Dependency Injection (DI) へのリファクタリングの契機とすることもできるでしょう。 続きを読む
特集「部品と部品の関係を切り離す」（1）
図1●コンポーネント間の依存性 オブジェクトが他のオブジェクトを利用する場合，最も単純な方法がオブジェクトを生成したり，呼び出したりするコードを直接記述するやり方だ。これは，両者を結ぶ釘の頭が呼び出す側のオブジェクトに入り込んでいる状態と言える。利用される側のオブジェクトは釘から容易に抜けるが，頭が入っているオブジェクトの再利用は難しい。両方の釘を抜けるようにするには，何らかの媒介する仕組みが必要である。 図2●Dependency Injection（DI） JavaやC＃には，クラスの階層構造と関係なく，共通のメソッドを定義するための「interface（インタフェース）」という仕組みがある。通常，あるインタフェース（interfaceX）を実装したオブジェクトを利用したいクラス（classA）は，そのインタフェースを実装したクラス（classB）を指定し，生成する必要がある（a）。こ
DIContainerへの注釈 - Tociyuki::Diary
PerlによるDependency Injection (DI)のとってもシンプルなデモを読む上でのポイントを書いておきます。 ⇒ https://tociyuki.sakura.ne.jp/archive/didemo.pl ポイント1. バインド記述の末端要素は文字列です コードリファレンスなど使っていません。これでVMの内部リソースからバインド記述を分離することができます。 ポイント2. バインド記述は外部リソースに分離可 デモを一つにまとめるためにバインド記述をソースコードに含めましたが、無名ハッシュ部分を外部ファイルに移し、それを読み込んでevalするように変更すると外部リソースに分離できます。 ポイント3. コンストラクタ Perl5ではコンストラクタは必ずしも必要ではありませんが、それではDIコンテナが書けませんので、名前をnewに固定しパラメータなしで呼び出し可能と仮定しま
DI コンテナ:回り道日記
頭では理解できるDIコンテナ。ほんとに必要なのかいまいちわからない。でもEJBの効率の悪さを軽減解消するために使うことがちょっとわかりました。 開発効率の向上の事例も目にし、メリットを知りました。 メンテナンスが楽になるし設定も楽になるんです。 愛の国のあのお方もとても喜ばれておいででした。
Dependency Injectionとは、なにか (arclamp.jp アークランプ)
先のエントリ、「POJOがしめすアプリケーションの形」に対して、クープルのjugyoさんから指摘をいただいた。（この人「頭固いな～」と思った。） つまり「DIコンテナ」ってのはバーチャルマシンの一種なんだよ。 なんでみんなPOJOとかDIとかっていう難しい言葉で表現しようとするかな～。 うーん、ま、僕の表現が小難しいのはお許し願うとして、言い訳させてもらえれば、先のエントリは、DIコンテナを説明したかったのではなくて、POJOやDIで、何が出来るのかを説明したかったのだ。 現在、DIといえば、DIコンテナ（Spring Framework、Seasar2など）、いわゆる軽量コンテナである。DIコンテナでも、DIの効果は十分に証明されている。しかし、DIという概念そのものは、もっと応用性が高いのではないかと言われている。ま、DIコンテナ自身も、すべての可能性が洗い出されたわけでもないのだが
Dependency Injection (DI) の乱用！？ [それはBooks]
Dependency Injection (DI) は、「依存性の注入」という言葉で最近話題になっています。「EJB は重過ぎて使えない」とか「軽量コンテナは疎結合だからすばらしい」といった声をよく聞くようになりました。 Dependency Injection (DI) はサービスコンポーネント間の関係を疎に保ったままアプリケーションを構築するというものです。「設定を利用から分離する」という原則が、DIの本質です。 いろんな書籍が出始めてきた中で、依存性注入の何がステキなのか、疎結合だと幸せだよねといったことは非常に良く分かるようになりました。それでも、自分の中で何かしらの引っ掛かりがあります。それをつらつら書き連ねてしまおうかと思っています。 参考： Inversion of Control コンテナと Dependency Injection パターン 感じたこと DIコンテナの役
Inversion of Control コンテナと Dependency Injection パターン
以下の文章は、Martin Fowler の「Inversion of Control Containers and the Dependency Injection pattern」を、かくたにが翻訳したものです。原著者の許可を得て翻訳・公開しています。 翻訳にあたっては、kdmsnr さんにご協力をいただきました。ありがとうございます。公開後の改訂履歴を記事の最後に記述しています。 Java コミュニティでは軽量コンテナが花盛りである。 軽量コンテナは、異なるプロジェクトのコンポーネントをひとまとまりのアプリケーションとして組み立てることを支援する。 このようなコンテナの根底には、コンポーネントの結び付け方についての共通したパターンがある。 そのパターンのコンセプトは「Inversion of Control(制御の反転)」と、まことに包括的な名前で呼ばれている。 本記事では、このパタ
Inversion of Control Containers and the Dependency Injection pattern
Inversion of Control Containers and the Dependency Injection pattern In the Java community there's been a rush of lightweight containers that help to assemble components from different projects into a cohesive application. Underlying these containers is a common pattern to how they perform the wiring, a concept they refer under the very generic name of “Inversion of Control”. In this article I dig
＠IT：Spring Frameworkで理解するDI（1）
DI：依存性の注入とは何か？：Spring Frameworkで理解するDI（1）（1/3 ページ） Javaのエンジニアであれば最近、「Dependency Injection」や「DIコンテナ」「Spring」、または「Seaser2」といった名前を目にしたことがあるのではないでしょうか。これらは次世代のEJB（EJB 3.0）に取り込まれる動きがあるなど、最近非常に注目されているキーワードであり、今後のJava開発を語るうえで避けては通れない概念の1つになるとされています。 この連載は、「Spring」というフレームワークを利用して、J2EE開発における「Dependency Injection（DI）」というデザインパターンから得られるメリットを紹介し、J2EEの今後の方向性を理解する助けとしていただくことを目的としています。 Dependency Injection：依存性の注入
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
