Extensions as Aspects - asatoの技術的な内容の日記

基本的に、何かのソフトウェアやライブラリを拡張（or 変更）したい場合に取れるアプローチには:

ソースコードを直接変更
継承（or サブクラス化）

がある。

前者のアプローチの問題点は、変更される側（つまり、ライブラリ側）の変更に、変更する側が同期をとらなければならないということ。つまり、ライブラリ側のソースが変更（or 新しいリリース）になるたびに、再びソースを変更することが要求される。したがって invasive なことになる。

最近の技術では、これらのアプローチに加えて、変更や拡張を外部から可能にするようなのが色々出てきている。AspectJ もそのような技術のうちの一つ。したがって、non-invasive な方法で拡張や変更が可能になる。

ということで、そのような使い方の例として QDox を拡張してみた。

QDox Extension
http://www.ncfreak.com/asato/software/qdox.html

動機は、JavaDocBuilder のインタフェースに、getClasses() メソッドはあるけど、特定の条件を満たすような JavaClass を返すようなメソッドがないということから。

で、File クラスとかで定義されているのに似たような動作をする、Filter を受け取るメソッドを外部から（AspectJ の用語でいえば Inter-type declarations）追加してみた: JavaClass[] JavaDocBuilder.getClasses(JavaClassFilter)。

いくつかの疑問は:

パッチとの違いは？参考: Semantic Patches

普通に、サードパーティ（たとえばでは QDox）のクラス（たとえば JavaDocBuilder）をラップ（or サブクラス化）するようなクラスを用意するのでは、何がダメなの？あるいは、違いは？

AspectJ の機能は、このような、外部から（or non-invasive）ライブラリを拡張や変更するよう要求に対して、適切か？

non-invasive を要求された場合に、どのような機能を持っているツールや言語が適切か？

どのような拡張要件でも、どのような変更要件でも、アスペクトで対処できるのか？実際、どのような（区別できる）種類の拡張要求や変更要件があり、それぞれの種類から見た場合、いつ、どんなときに、たとえば、AspectJ の機能が十分でなくなるのか？

拡張や変更の衝突の取り扱いはどうなる？たとえば、ライブラリX に、複数のライブラリ拡張 A, B があるとして、それぞれの拡張は、同時に、ライブラリ X に一貫して適用できるのか？どのような順番で適用するかによる非一貫性は無いのか？

リソース:

Robert Hirschfeld, Kasper Osterbye, Matthias Wagner.
System Integration Using AOP.
In Proceedings of the Third GI-SIG 2.1.9 Workshop on Aspect-Oriented Software Development, University of Duisburg-Essen, pages 1-6, Essen, Germany, March 4-5, 2003.

DL: http://citeseer.ist.psu.edu/hirschfeld03system.html

Robert Hirschfeld and David H. Lorenz.
Non-Invasive On-Demand Changes: Applying Change-Sets as Aspects.
Technical Report NU-CCIS-03-08, College of Computer and Information Science, Northeastern University, March 2003. (2003)

DL: http://www.ccs.neu.edu/home/lorenz/papers/reports/NU-CCIS-03-08.html