タグ

AOPに関するchigurihaguriのブックマーク (8)

  • Dependency Injection (DI) の乱用!? [それはBooks]

    Dependency Injection (DI) は、「依存性の注入」という言葉で最近話題になっています。「EJB は重過ぎて使えない」とか「軽量コンテナは疎結合だからすばらしい」といった声をよく聞くようになりました。 Dependency Injection (DI) はサービスコンポーネント間の関係を疎に保ったままアプリケーションを構築するというものです。「設定を利用から分離する」という原則が、DIの質です。 いろんな書籍が出始めてきた中で、依存性注入の何がステキなのか、疎結合だと幸せだよねといったことは非常に良く分かるようになりました。それでも、自分の中で何かしらの引っ掛かりがあります。それをつらつら書き連ねてしまおうかと思っています。 参考: Inversion of Control コンテナと Dependency Injection パターン 感じたこと DIコンテナの役

  • https://www.atmarkit.co.jp/misc/search/marker.php?pg=www.atmarkit.co.jp/farc/rensai/uml_b_l10/uml_b_l10c.html&query=%A5%A2%A5%B9%A5%DA%A5%AF%A5%C8

  • プログラム間にボタンを掛ける「DI/AOP」(前編)

    「DI(Dependency Injection)」および「AOP(Aspect Oriented Programming)」と呼ばれる技術が注目を集めている。これらはオブジェクト指向プログラミングにおけるプログラムの単位であるクラスを,互いに結び付ける新たな技術である。システムへの機能変更ニーズが高くなり,さらに開発期間が短くなっている開発の現場において,開発の効率化や品質向上を実現する新たな手段として期待されている。まずはオブジェクト指向プログラミングにおける課題を明らかにし,DIやAOPがそれらをどう解決できるのかを見よう。 DIでクラスを容易に付け外す オブジェクト指向プログラミングの一つ目の課題として,「変更時にクラスの修正が必要になる」ことがある。そもそも,オブジェクト指向で開発したプログラムは,オブジェクト指向ではないプログラムと比べ,機能の削除や変更が容易であることが特徴だ

    プログラム間にボタンを掛ける「DI/AOP」(前編)
  • AOSD アスペクト指向をユースケースに、日本語版出来。(^_^):An Agile Way:オルタナティブ・ブログ

    ついに出ました。ヤコブソンのの日語版です。ヤコブソンは、80年代後半-90年代前半に「ユースケース」という新概念をオブジェクト指向に持ち込み、設計以前の要求キャプチャに大きな貢献を果たしているが、今回は、アスペクト指向をユースケースに応用しようという野心的な試みだ。 Ivar Jacobson, Pan-Wei Ng 著, 鷲崎弘宜, 太田健一郎, 鹿糠秀行, 立堀道昭 訳 『ユースケースによるアスペクト指向ソフトウェア開発』, 翔泳社, ISBN 4798108960, 2006.3 http://www.amazon.co.jp/exec/obidos/ASIN/4798108960/xpjp-22 ずいぶん以前から親しくしていただいている、鷲崎さん、太田さんが訳されている。(お疲れ様でした!) ソフトウェア分析・設計の新技術は、「実装レベルから発見される」ことが非常に多い。オブジ

    AOSD アスペクト指向をユースケースに、日本語版出来。(^_^):An Agile Way:オルタナティブ・ブログ
  • 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

  • アーキテクトの審美眼

    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機能のデモを行った。データベースにはPureJavaRDBMS「H2」を使い、エンティティクラスやサービスクラス、テストクラスまでも自動生成される様子や再

  • J2EEアプリケーションにおけるAOPを使ったフェッチ戦略の実装

    注意:問い合わせの際に二次キャッシュにあるデータを熱心にフェッチ(eager fetch)しているとしたら上記の問題に対する解決策をとることは出来ません。O/Rマッピング・ツールのHibernateでは、もし二次キャッシュにあるデータに対して熱心なフェッチ(eager fetch)を使うと例えそのデータが既に二次キャッシュ内に存在してたとしてもキャッシュからではなくデータベースからデータを取得することになるでしょう。Hibernateでは上記の問題に対する解決策はありません。このことは二次キャッシュにあるオブジェクトに対する問い合わせでは決して熱心なフェッチを使うべきではないということを暗示しています。 オブジェクトに対する問い合わせに関するチューニングが出来るO/Rマッピング・ツールをキャッシュを利用するように設定している場合、問い合わせ対象のオブジェクトが既にキャッシュ上に存在していれ

    chigurihaguri
    chigurihaguri 2009/05/27
    ドメインモデルで実装した際の性能劣化問題に対する解決策
  • 1