Dependency Injection (DI) の乱用！？ [それはBooks]
Dependency Injection (DI) は、「依存性の注入」という言葉で最近話題になっています。「EJB は重過ぎて使えない」とか「軽量コンテナは疎結合だからすばらしい」といった声をよく聞くようになりました。 Dependency Injection (DI) はサービスコンポーネント間の関係を疎に保ったままアプリケーションを構築するというものです。「設定を利用から分離する」という原則が、DIの本質です。 いろんな書籍が出始めてきた中で、依存性注入の何がステキなのか、疎結合だと幸せだよねといったことは非常に良く分かるようになりました。それでも、自分の中で何かしらの引っ掛かりがあります。それをつらつら書き連ねてしまおうかと思っています。 参考： Inversion of Control コンテナと Dependency Injection パターン 感じたこと DIコンテナの役
プログラム間にボタンを掛ける「DI/AOP」（前編）
「DI（Dependency Injection）」および「AOP（Aspect Oriented Programming）」と呼ばれる技術が注目を集めている。これらはオブジェクト指向プログラミングにおけるプログラムの単位であるクラスを，互いに結び付ける新たな技術である。システムへの機能変更ニーズが高くなり，さらに開発期間が短くなっている開発の現場において，開発の効率化や品質向上を実現する新たな手段として期待されている。まずはオブジェクト指向プログラミングにおける課題を明らかにし，DIやAOPがそれらをどう解決できるのかを見よう。 DIでクラスを容易に付け外す オブジェクト指向プログラミングの一つ目の課題として，「変更時にクラスの修正が必要になる」ことがある。そもそも，オブジェクト指向で開発したプログラムは，オブジェクト指向ではないプログラムと比べ，機能の削除や変更が容易であることが特徴だ
アーキテクトの審美眼
MS萩原さんのセッション。同名の書籍（元ネタはDBマガジンの同名の連載）が元になっていて、そのダイジェスト版＋最新の動向の補足、という形。とても示唆に富んでいるんだけど、抽象的な上に、1つ1つのトピックがめちゃめちゃ重たいので、きちんと理解しようとすると調べる量がとても多くなってしまう上に、そもそも理解しきるのが難しすぎる。とりあえずは現段階の自分の稚拙な理解をもとに、こんなことじゃないかなーと補足しながら書いていく。 アーキテクチャの原則アーキテクトにとっては、アーキテクチャの原則を理解することが重要。アーキテクチャの原則は、インフラなどが変化しても変わらず、クラウドでも通用する。 アーキテクチャ先行定義の原則アーキテクチャは先行定義せねばならぬ、という原則。アーキテクチャ設計を含むソフトウェア開発は、こんな風な流れになるはず。 モデリングとアーキテクチャ設計の双方のインプットとして、シ
DI×AOPのこれまで、Seasarの今、そしてSlim3へ… (2/2) - ＠IT
DI×AOPのこれまで、 Seasarの今、 そしてSlim3へ… 「Seasar Conference 2009 White」レポート ＠IT編集部 平田修 2009/4/2 「Seasarは2.4を安定したバージョンとしたい」 SeasarプロジェクトのもたらしたプロダクトSeasar2の最新形はどのような恩恵を開発者にもたらすのか。ひが氏のセッション「Seasar2の今と未来」からお届けしよう。 ひが氏は、EclipseプラグインのDoltengでSAStrutsとS2JDBCを使ったWebアプリケーションをScaffold（自動生成）して作成し、ソースコードの変更もアプリケーションサーバの再起動なしで実現するHOT deploy機能のデモを行った。データベースにはPureJavaのRDBMS「H2」を使い、エンティティクラスやサービスクラス、テストクラスまでも自動生成される様子や再
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://patterns-wg.fuka.info.waseda.ac.jp/st/index.php?%5B%5B%C2%E81%B2%F3J2EE%2FDI%2FAspect%A5%D1%A5%BF%A1%BC%A5%F3%CA%D9%B6%AF%B2%F1%B5%C4%BB%F6%CF%BF%5D%5D
