コントラクトを普通のJavaクラスとして実装する

yoshiさんにおしえて頂いたページに紹介されていた、Contract自体は普通のJavaクラスとして記述し、Contractを呼び出す箇所のみをAspectとして記述するアプローチには大きく分けて2つのメリットがあると思います。

1.eclispeのJDTの機能をフルに活かせる
eclipseはいまやJavaの開発環境のデファクトスタンダードになっています。そのeclipseのAspectJプラグインであるAJDTでは、JDTの強力な機能である、ソースコード補完やリファクタリング機能の多くが使えません。シンタックスハイライトが聞いたエディタくらいのイメージでとらえたほうがしっくり来ます。コントラクトをPureJavaで書けるとJDTの優れた機能をそのまま使えるというメリットがあります。

2.Javaソースコードを解析する各種ツールを使用できる。
コントラクトはプログラムの仕様です。ソースコードそのままでも意味的には仕様書として通用するとは思いますが、大抵の環境では、仕様書というのはMS-WordやHTMLなどの形式で書くものだという
固定観念に囚われているのが普通です。そのような環境向けには、
ソースコードに書かれた情報をMS-WordやHTMLのような形式に変換してあげるのが良いとおもいますが、コントラクトがAspectJで書かれているとそれがうまく行きません。AspectJの構文を解析して、
その構造にアクセス出来るツールが僕の知る限りまだ存在
しないのです。
それに対してコントラクトがJavaソースコードで書かれていれば、
qdoxなどのツールを使用してコントラクトの情報を他の形式に比較的簡単に変換できそうです。

ただし、紹介されていた通りの方式でコントラクトを実装してしまうと、メソッド一つ毎に一つJavaクラスと対応するアスペクトを作成しなければならなくなります。それではあまりにも煩雑です。

そこで、JUnitがtestXXXという名前のメソッドをテストメソッドとして自動的に展開するようにpre_XXXとかpost_XXXという名前付けルールで事前条件/事後条件チェックに対応するメソッドを起動するように工夫すれば、一クラスあたり一つのコントラクト用クラスを作成すれば良くなって煩雑さが少し軽減されます。

時間をみつけてこのアイデアを実現させる方向で考えてみたいと思っています。