設定とAnnotationと実装と。その2

AnnotationがXDoclet化するとダメなのは、
XDocletによる記述は、最終的に出力される「設定」の一時的な記述領域でしか無い為。との事。
要は、XDocletを使って出力されたXMLファイルを、全く触らずに運用していくのは
現実的に不可能に近いからなんですね。


id:masataka_kさんも仰っていますが、
Annotationによってコードに意味付けが為される事には大きな価値があると思います。
例えば、今までマーカインターフェースと言う実装ギミックがありました。
java.io.Serializableの様に、メソッドを持たないインターフェースの事です。
これは、フレームワークが、何らかの形で「実装」を自動的に扱う時、
大きな助けになります。


と、言う訳で、今日はちょっとだけ、コードモドキを書いてみたり。
ちなみに、Annotationの名前付けは、雰囲気をだす為のもので、かなりいい加減に付けてます。

@service
public interface Hoge {
  public void doSomething();
}
@component // コンテナがデプロイする対象である事を表す……みたいな。
public class HogeImpl implements Hoge {
・・・・
}
@notComponent // コンテナがデプロイする対象でない事を表す……みたいな。
public class HogeUtil {
  public static final String doIt(int num) {
      ・・・・
  }
}
@notComponent
public class FugaDto {
  public int getId() { return id; }
  public void setId(int num) { this.id = num; }


もしくは、今までアプリケーションレイヤーを表現する為に、
パッケージ名を使っていたのを、Annotationで記述出来る事により、
クラスをより具体的かつ論理的にグループ分け出来るようになったりするかと思います。

@layer(Action)  // 例によってAnnotationの名前は、雰囲気だけ、テキトー。
public class HogeAction extends BaseAction {
    public String execute() {
       ・・・・
    }
}
@layer(Logic)
public class MogeLogicImpl implements MogeLogic {
    public MogeDto doSomething() {
       ・・・・
    }
}
@layer(Dao)
public interface FugaDao {
    public List select(String id);
}

昨日の話からすると、こういうAnnotationの使い方は、
濫用かな…と言う気もしますが…
クラスを論理的にグループ分け出来る事によって、
各グループ毎に適用するAspectを変える。みたいな事も可能になります。


ここで、ちょっとだけ視点を変えて、「メタ情報」について考えてみます。
例えば、リファクタリングのし易さ。
最初は、Annotationとしてクラスにマーキングしていたけれども、
後から、そのマーキングが為されたクラス全てが実装するべきメソッドが
現れたりする場合。
Annotationを普通のinterfaceにし、宣言方法を変更するだけで対応出来ます。*1
「メタ情報」と「実装」がセットになっていなければ、
これは実現が難しいと思います。
もし、「メタ情報」と「設定」がセットになっているならば、
修正するべき対象を、何かコンパイラとは別な手段で用意しなければなりません。


と、言う所で、何かもっとあったような気がするものの、今日はここまで。

*1:まずは、Aspectで対応出来るか考えるべきかも……