Cotton Bolls: アスペクト指向のデザインパターン的解釈
Document Actions
« Type Safe Enumパターンの謎のクラス | トップページ | テストファーストの判断基準 »
2004.01.25
アスペクト指向のデザインパターン的解釈
先日AspectJ in Actionという本を読み終えた．AspectJを実際に仕事で使ったことはないが，こういう新しい機能を見ていると昔C++でtemplateや多重継承で悩んでいたことを思い出す．仕組みも理解できるし，かなり強力なツールであることもわかる．しかし，どう使えばいいかわからないのだ．そのためどうしても負の面だけが見えて懐疑的・保守的になってしまう．
templateと多重継承の場合は，そういった疑念を一気に打ち払うキラーアプリがあった．STLとMix-inアーキテクチャだ．どちらもtemplateと多重継承の見方を180度変えるすばらしいものだった．アスペクト指向にもそういう目の覚めるようなものが一つ出てくればいいなと思う．もちろん，AspectJ in Actionにも有用な例はたくさん出ている．しかし，180度見方を変える…とまでは行かない．とはいえ，これからもっと面白いものが出てきそうな気配は十分にあった．
アスペクト指向は，GoFのMediatorパターンに似ているような気がする．正確には，ObserverパターンとMediatorパターンの合わせ技というべきか．
Mediatorパターンでは，いろいろなオブジェクトの相互作用をひとつのクラスにまとめてプログラムを簡潔にする．この一極集中のやり方はアスペクト指向のAspectに相当しているといえるだろう．
また，MediatorクラスはObserverパターンを使って各オブジェクトのイベントをフックすることが多い．イベントが起こったとき，他のオブジェクトに指示を与えて相互作用させるわけだ．イベントをフックする部分はpointcut，相互作用させるコードはadviceに相当しているといえるだろう．
もちろん，Mediatorとアスペクト指向は異なる部分も多い．まず適用される規模が全然違う．Mediatorパターンならダイアログにあるウィジェットを管理するので精一杯だろうが，アスペクト指向ならシステム全体に影響を与えることも簡単だ．
また，pointcutは静的に宣言されるのに対し，Observerパターンによるイベントのフックは動的に行われる．この部分だけはMediatorのほうに分があるかもしれない（注：AspectJしか知らないので間違っているかも．他の実装なら動的に決められるのかもしれない）．
結局何が言いたかったかというと，アスペクト指向の適用するとき，これをシステム規模のMediatorパターンとみなせば何かヒントが見えるかもしれない，ということだ．本当はCross Cutting Concernが基本だろうが，オブジェクト指向に慣れた人ならMediatorパターンのほうが考えやすいかな，と思った．
10:37 PM in AOP | 固定リンク
トラックバック
この記事のトラックバックURL:
http://app.cocolog-nifty.com/t/trackback/135268
この記事へのトラックバック一覧です: アスペクト指向のデザインパターン的解釈: