続・DAOはアスペクト？

Java AOP Seasar
私の感覚では、AOPはInterceptorです。crosscutting concernも
実現できるという感じです。

なるほど，そういう考え方ですか．割り切りがいいなぁ．(^^;
この割り切りの良さがS2のシンプルさにつながっているのでしょうね．自分はちょっと割り切りが足りないのかも．中森明菜の歌で「割り切りの，良さぁは，AB型ね♪」って感じの曲があったのですが，そうでもないようです．ちなみに明菜は(歌の中でも)A型で，明菜を惑わせる男はO型でした．さすが．
そんなことはどうでもよくて，私の割り切れない想いは次のような感じ．

  • AOPというのはアスペクトを活用するプログラミング．
  • アスペクトというのは cross-cutting concern をモジュール化したもの．
  • Interceptor というのはメカニズム．
  • AOP は S2 のように Interceptor で実現されることもあるし，AspectJ のように異なった方法で実現される場合もある．
  • Interceptor は AOP を実現するために使われる場合もあるし，それ以外のために使われる場合もある．

どうも，このような考え方にとらわれてしまっているようです．
そして S2Dao で感じた違和感というのは，AOP を実現するために(たまたま)用意されているらしい Interceptor というメカニズムを，AOP 以外の目的のために使っているように見えたことに原因があるのでしょう．


ではどのような実装だったら違和感を感じなかったのか？
S2Dao の場合，一つの DAO 実装を様々なインタフェースに適合させるための動的なアダプタとしてInterceptor を使っているわけですから，

  • データアクセスそのものがcore concern
  • 様々なインタフェースへ適合させるアダプタが cross-cutting concern

と考えるとどうでしょうか？
悪くない気はするのですが，メリットもない感じ．

  • コンテナの実装は変わらない．
  • DAO の実装はあまり変わらない(たぶん)．
  • dicon の記述が煩雑になる( <aspect> の内側でユーザ定義のインタフェースを指定するため)

1敗2分けです．メリットがないのではなく，デメリットしかありません．無念だ．
ちなみに昨日書いた Spring 風 FactoryBean だと，

  • コンテナの実装は複雑化．
  • DAO の実装はあまり変わらない(たぶん)．
  • dicon の記述はほとんど同じ．

こちらも1敗2分けですか．心より恥じる．
うーん，ダメダメですね．


このように検討してみると，S2Dao の選択はきわめて合理的であるようです．コンテナ・S2Dao ともに簡潔に実装されていて，使い勝手も優れているわけですから．
それに違和感を感じるということは，どうやらおかしいのは S2Dao ではなくて，この私の頭のようです．心より恥じる．
ということで，S2Dao は正しくて，間違っているのは私の既成観念(メンタルモデル)であるという前提で，もう少し考えてみることにしました．
スポーツなんかでは，常識はずれの天才選手が出現した場合，最初は奇異に受け取られても，その後天才選手の優れているところが分析されて新しい常識になったりしますよね．S2Dao とその作者・ひがさんは私にとってそのような存在なのかもしれません．
ということで，もう一度 S2Dao の dicon ファイルを確認．

<component class="foo.FooDao">
    <aspect>
        <component class="org.seasar.dao.interceptors.S2DaoInterceptor"/>
    </aspect>
</component>

これは正しいはずなのです．つまり，<component> 要素は core concern を，<aspect> 要素は cross-cutting concern を示しているはずです．
ということは，FooDao は core concern．S2DaoInterceptor は cross-cutting concern．むむぅ．
．．．
はっ！！
もしかしてもしかするともしかするのかぁっ！！

  • インタフェースは core concern．
  • 実装は cross-cutting concern．


うおおおおおおおおぉぉぉぉぉぉぉぉぉっ！！！！
妥当性はともかく，自分にとっては新しい見方・考え方です．新境地を開拓という感じ？ おっと，新境地とはいってもひがさんには既知の世界かもですが．
うーみゅ，いろいろ考えてみるものですねぇ．そうかぁ，そういう発想もできるかもしれないなぁ．


さらに考えてみたところ，昨日の FactoryBean 方式の場合，

<component class="DaoFactoryBean">
    <arg>FooDao.class</arg>
</component>

という記述になりそうと書いたわけですが，これが不自然に思えてきました．
ここで利用者にとって中心的な関心は DAO の実装ではなくインタフェースです．つまり，FooDao なのです．
しかし，その FooDao よりも DaoFacotoryBean の方が主体であるように見えてしまいます．
ということは，先ほどの星取り表は間違いで，

  • コンテナの実装は複雑化．
  • DAO の実装はあまり変わらない(たぶん)．
  • dicon の記述が利用者の意識と合わなくなる．

ということになるような．2敗1分け，ダメダメですがな．


ともあれ，やっぱり「ひがさんすげー」ってのが結論．間違いない．