Aspect-aware Design or Aspect-aware Refactoring

Bruno Harbulot and John R. Gurd.
Using AspectJ to Separate Concerns in Parallel Scientific Java Code.
To be published in the Proceedings of the 3rd International Conference on Aspect-Oriented Software Development (AOSD). March 2004.

DL: http://www.cs.man.ac.uk/cnc/students/harbulob/
を読んでいて、曖昧から確信に変わったんだけど、アスペクトを意識した設計(クラス構成、メソッド構成)とか、アスペクトを意識したリファクタリングとかが存在する気がする。


アスペクトを意識するとは、ここでは、アスペクトがうまく適用できるような設計にしたり、アスペクトがうまく適用できるようにリファクタリングを行うこと、みたいな雰囲気。


でも、そういうのってどうなんだろう? っていうのは、一つは、もし、アスペクトを気にしないとしたら、設計はよりシンプルになってるまま、ってのもありえると思うから。二つ目は、関連することだけど、アスペクトが適用されるベースのコードだけを見て、意図をちゃんとつかみ取れるのか、と思うから。つまり、なぜそんな設計になっているのかを知るには、アスペクトをうまく適用したかったから、というような意図を、ベースのコードからはうまくつかみ取れない気がするから。


どっちにしろトレードオフの問題かもしれない。アスペクトを使っているということは、一般的には、他の、tangled-code とか scattered-code の問題があるからなので、その問題のほうが大きいのであれば、ちょっとぐらいの設計の適応は、我慢できるものなのかもしれない。


とはいえ、あるいは、現在の AOP の技術や言語的な特徴が、単に能力不足、という可能性も考えられる(たとえば、for-loop の join point が無いなど)。


疑問:

  • アスペクトを意識した設計は、どのくらい一般的なものなのだろうか? まれ? 頻繁?
  • ベースプログラムを書く人と、そのプログラムにアスペクトを適用したい人とが、同じ人とは限らない。ベースプログラムを書く人は、そのようなアスペクトを適用したい人の存在を考えて、プログラムを設計すべきか?
  • もしそうなら、一般的に使えるような、法則集(パターン)は、存在するか? オブジェクト指向の例でいえば、自分のクラスを使いやすいように(拡張しやすいように)、いろいろと拡張点(or ホットスポット)をあらかじめ用意しておくなど。
  • もし、アスペクトを適用しにくいという状況であるのなら、それは、ベースのコード(アスペクトがウィーブされる側)の設計がもともと悪かったからなのか? or うまく設計されたベースコードほど、アスペクトが適用しやすい?
  • アスペクトを意識した、ベースコードの設計は、再利用性にどのような影響を与える? or アスペクトをうまく適用できるようにプログラムを変更することは、再利用性にどのような影響を与える?