AOPの実践投入をためらう理由

先日に引き続きは大学でAOPに関するミーティング&ディスカッションに出席。

後輩たちはそろそろ来月の中間発表に向けての仕上げに入っていかなければならないので、今後の予定を決定しました。

† 僕はAOPが好きです

まず誤解がないように述べておきますが、僕はAnti-AOPなわけではありません。個人的にはAOPはとても面白いと思いますし、将来性もあるという見方をしています。

僕はいちおう現役のエンジニアですので、学生よりは実用性についての議論ができると思っています。そこで、今回のディスカッションではあえて「現状では使えない」という立場に立ち、後輩にその理由をひとつずつ潰してもらうという研究体制になっています。

† これまでのおさらい

先日から話題になっていう話の発端は

「AOPの機構を使ってテスト支援をするという試みはよくあるみたいだけど、Aspect自体のテストはどうしたらいいのかなぁ」

という僕の素朴な疑問にあったりします。そもそもテストができないようなものを実践投入するなんて不可能なわけですから。

ということで、Aspectというモジュールに対して

「どのようなリスクが存在しているのか？」
「どのようにテストをしたらよいのか？」
「どのようなテストが必要なのか？」
「どのようなテストが可能なのか？」

ということをまとめた上で

「Aspectに対するテスト手法を提案する」

ということになります。

† 単体テストができない

Javaで大ヒットとなったJUnitのようなものが開発されれば一発で解決なのですが、このようなツールはまだないようです。

そもそも、Aspectは対象となるClassとweavingさせないと実行することができないのでそのあたりをどうするのかということも問題です。アプローチとしてはJUnitのようなドライバのフレームワークだけでなくスタブも生成するフレームワークを作ってしまうという作戦が考えられるでしょうか。

† 実行時のContext

まず、僕が考えるAOPのリスクとしてはデバッグのしにくさだろうと思います。Aspectはそのプログラムが実行されているContextによって挙動が変わってきます。

したがって、デバックやテストを行うには、これまでのテスト方法のようなプログラムの条件を網羅するだけでなく、Aspectに対するContextも網羅する必要が生じてきます。現状ではそのようなテストケース設定を行うことを考えると、開発者に対して高度なスキルを要求し、相当の負担がかかると考えられます。

† Methodのsignitureに敏感であること

現在、一部を除いてMethodの命名についてはプログラマーの裁量とセンスとされています。通常、Aspectの結合点(join point)はメソッドの呼び出しの部分になります。そのため、対象となるMethodのsignatureの変更、追加を不用意に行ったりすると、思わぬ副作用が出る可能性があります。場合によっては、CLASSPATHにjarを追加するだけで・・・ということも十分に考えられます。

これは、プログラムの進化やリファクタリングに対して大きなハンデになります。この辺については、join pointの可視化ツールぐらいしかアイディアは浮かんできません。消極的な解決方法が許されるならば設計法という部分にまで発想を広げてDesign by Contractを徹底するというような方法で乗り越えられるような気もしなくはないです。

まぁ、AOPが常識になれば命名規則とかが現在よりは徹底されてくるはず^*1なので、このへんは時間とともに自然に解決される問題という感じもしています。

† aspect同士の依存性

そういうモジュールを作らない方がいいといろんなところに書いてありますが、細かいモジュールがたくさんできてくると、そういうことが最終的にわからなくなってくるので、そういうことを教えてくれるツールもあったらいいかもしれません。

† aspect指向方法論

最後に、AOPはまだまだ発展途上の技術であり、どのような場面、どのような機能で使ったら効果的なのかということがいまいち良くわかっていないという点があります。そのあたりを整理したaspect指向方法論というものが欲しくなってきますね。

† 課題はいろいろあるけれど

とりあえず、チームは「単体テストができない」にターゲットを絞ってくれているようです。どんなことが提案されてくるかということについては、お楽しみにということで。

• ^*1: JavaBeansのsetter,getterという命名方法が普及したようにというイメージです。