新ドラえもん見た

なんだ。押し入れがウォークインクローゼットになっているというのはデマだったのか。

続: Annotation Based AOP

http://www-128.ibm.com/developerworks/java/library/j-aopwork3/
http://www-106.ibm.com/developerworks/java/library/j-aopwork4/

1本目の記事は、Version5の形がおもしろい。

public class Customer {
  public void setAddress(Address addr) {
  }

  public void addAccount(Account acc) {
  }

  public void removeAccount(Account acc) {
  }

  private static aspect Annotator {
    declare annotation: public Customer.*(..): @Transactional;
  }
}

こんな感じで、メソッド毎にannotation付けるんじゃなく、内部アスペクトを定義して、アノテーションイントロダクションを使って定義。メソッドに付加されるアノテーションがやたら増えてしまうケース(設計まずいっぽいけど)もありそうだから、可読性のためにこれ使うのはあり。


2本目が本題で、メタデータアノテーションをインターフェースとして使うという概念を明示している。ポイントカットをアノテーションの集合で表現することで、アスペクトのモジュール性が向上する。今後メソッドのシグネチャを頼りにしたAOPは減っていくはず。

月給594円の社長

http://www.nikkei.co.jp/news/main/20050426AT1D2609R26042005.html
いや、なにをどう思い詰めたらそういう発想になるのですか。

悩みどころ

より上流を攻める(マネージャ or コンサル)べきか、今を掘り下げる(エンジニア or 研究者)べきか。

う～ん。迷い出すときりがない。

迷ってるときは、まだ何かが足りない時だ。意識してないけど、重要で決定的な何かが。

Annotation Based AOP

構造ではなく、metadata annotationでjoinpointを表現しよう。

これは対象コードの復権だ。構造によるjoinpoint指定は非常に強力なんだけど、

• 結合が疎すぎて、対象コードから何もコントロールできない


• アスペクト側に対象コードに関する知識を必要とする

という問題点がある。

メタデータアノテーションを使うことで、対象コードからアスペクトの適用をある程度コントロールできるようになり、疎結合を保ちつつアスペクトに必要とされる対象コードの知識を最小限にできる。

研究ネタになるぞと暖めてたんだけど、世の中そんなに甘かないってことで、
関連記事:
AOP and metadata: A perfect match, Part 1
AOP and metadata: A perfect match, Part 2
さすがdeveloperWorksです。

活動

手始めにコンサルティング。

結婚、出産、加齢。状況が変化すると、求められる用件も変化する。
生活基盤は保守的に、仕事は革新的に。