アスペクト: アノテーションを扱うための簡単なツール？

作者 Srini Penchikala , 翻訳者 佐野 徹郎 投稿日 2008年9月28日

セクション

設計/アーキテクチャ,

デベロップメント

トピック

アノテーション ,

Java ,

AOP ,

言語 ,

方法論 ,

メタデータ ,

Architecture ,

プログラミング ,

Aspect Oriented Programming

共有 |

Ramnivas Laddad(リンク)は、トランザクション管理、キャッシュ、永続化、ロールベースセキュリティなど、横断的関心事に対する様々なアスペクトの考えについて、それらのもう1つの重要な価値は、通常のプロジェクトのためにアノテーション(リンク)を実現することだと述べる。

Java Metadata facility (JSR 175(リンク))としてJava SE 5.0(リンク)に追加されたアノテーションは、プログラム要素にメタデータを追加する方法を提供する。それはコンテナの設定、永続化設定の記述、セキュリティロールの設定に利用され、最近のほとんどのJSR標準でも定義されている。それはまた、リフレクションによるメタデータアノテーションに対するプログラム的なアクセスを提供するだけでなく、Javaコードにカスタムアノテーションを追加する仕組みも含んでいる。

AOP(Aspect-oriented Programming)(リンク)は、ロギングのような単純なユースケースから、アプリケーションセキュリティやトランザクション管理のような高度なユースケースまで、横断的関心事を実装するために利用されてきた。アノテーションハンドラの実装によるアスペクトの利用は、伝統的なアーキテクトが考える「横断的関心事」の観点とは異なる方法だ。アスペクトによるアノテーションの活用と、Javaアプリケーションに横断的な振る舞いを追加するためにカスタムアノテーションを利用するAOPについて、Ramnivasは述べた(リンク)。彼はメタデータとAOPが相互にもたらすものについて論じている。メタデータは、Pointcuts(リンク) がジョインポイントを捕らえるためにアノテーションを利用する際に、ジョインポイントを選択するための追加の情報をもたらす。それはまた、特定のユースケースにおいて、疎結合のアスペクトを作成するのにも役立つ。そしてAOPは、アノテーションの供給と消費のための、システマティックな方法をもたらす。AOPを利用するメタデータを供給することで、整然としたコードというメリットも得られる。AOPを利用するメタデータを消費することで、APT(Annotation Processing Tool)(リンク)オプションにはない、いくつかの利益を得られる。

Ramnivasは、Java言語を拡張するメタデータの利用は、強力だが危険でもあると警告する。一方では、アノテーションは言語をオープンにするので、コア言語を変更しなくてもJava言語に新しい機能を追加することができる。最善のシナリオでは、原則に基づいた拡張によってホスト言語のいくつかの限界を超えることができるかもしれない。他方では、非標準、アドホック、または一貫性のないアノテーションのセットは、理解しづらいコードをもたらすかもしれない。

AOPを最大限に活用するベストプラクティスの1つは、横断的関心事に対するジョインポイントを捕らえるために、メタデータを利用することだ。そのポイント(アクション)で何が起こるかではなく、ジョインポイント(状態)において何が真であるかを、アノテーションで記述しなければならないことに留意する。彼はまた、すでに開発者が利用している(@Entity(リンク)、@Table(リンク)、@WebService(リンク)などのような)アノテーションについても、提言している。最初に選択するメタデータやプログラミング要素自体に依存しないポイントカットについて考える。また、実装固有のアノテーションについても避ける。それはまた、メタデータとAOPを一緒に利用することの、コストとメリットを理解するのにも役立つ。メタデータは様々な方法で消費される可能性があり、こうした用途を理解することは、AOPとメタデータの組み合わせを把握するのに役立つだろう。RamnivasはAOPとメタデータの記事(パート(リンク)およびパート2(リンク))で、開発者がカスタムアノテーションを使い過ぎないよう提言するだけでなく、いくつかのベストプラクティスについても述べている。

カスタムアノテーションの実装における主な設計上の考慮事項は、何を(メタデータ、振る舞い)、いつ(コンパイル時、実行時)、どのように(APT、実行時リフレクション、AOP)、Javaアプリケーション内のアノテーションに適用するかということだ。John Heintzは先ごろ、Javaアノテーションに振る舞いを追加することに関するプレゼンテーション(リンク)で、Javaアプリケーションでカスタムアノテーションを実装するための、設計テクニックの違いについて比較を行った。Johnは、3種類のアノテーション処理の選択肢のうちの1つとして、アスペクトを含むバイトコードの変換について論じている。

• ジェネレータ: このアノテーション処理の選択肢には、ソースコードを読み込んで、新しいソースコードを生成したり、既存のソースコードを変更するものが含まれる。APTやXDocletはこのカテゴリに分類される。
• バイトコード変換: これらのアノテーションハンドラは、アノテーションによってクラスファイルを解析し、変更されたクラスや新たに生成されたクラスを出力する。それらはまた、XMLの設定ファイルのような、クラス以外のアーティファクトも生成する。バイトコード変換の例には、AspectJ(リンク)、Spring(リンク)、Hibernate(リンク)、CGLib(リンク)およびBCEL(リンク)が含まれる。
• 実行時リフレクション: この選択肢は、実行時にオブジェクトをプログラム的に検査するために、リフレクションAPIを利用する。実行時リフレクションの例は、Java 5以降のリフレクションやCommons Attributes(リンク)のようなライブラリだ。テスティングフレームワークのJUnit(リンク)やTestNG(リンク)は、アノテーションを処理するために、実行時リフレクションを利用している。

InfoQはJohnにカスタムアノテーションの実装におけるアスペクトの役割について話を聞いた。彼はカスタムアノテーションを実装するときに考慮すべきことは、単に力のバランス(エンジニアリングトレードオフ)であると述べた。彼はまた、アノテーションに対する振る舞いと集中型の定義を実装するための最も簡潔な方法を提供する、アスペクトベースのアノテーションの実装についても言及した。それでも開発者は、非ローカルなセマンティクスおよびビルドツールや開発ツール(コンパイルや実行時のウィービング)に与える影響について、明確に文書化しなければならない。

原文はこちらです：http://www.infoq.com/news/2008/09/aspects-annotations