annotation（設定情報の保持方式に関する論評）

設定情報の保持方式に関する論評です。

annotation反対派のご意見です。非難されていますが、建設的な代替案に関しても提示されているのではと考えます。
http://www.softwarereality.com/programming/annotations.jsp

設定情報をXMLからannotationに移行することにより、コードと設定情報の関連は変更されます。具合的には、コードとXMLの関係のmany-oneの関係から、コードとannotationの関係のone-oneの関係に変更されることとなります。また同時に、weakly-typedからstrong-typedな設定に変更されることになります。ここで筆者は、strong-typedな設定であると同時に、コードとXMLの間のmany-oneの関係を保つより良い方法があるのではとご提案されています。

ここでご提案されている方法は、XML-like の構造を Java のコードで実現する方法です。これにより、コードと設定のmany-oneの関係の利点を保ちながら、ビジネスオブジェクトから設定情報を分離する利点を得られます。

具体的な方式に関しては言及されていませんが、方式が持つべき構成要素に関して述べています。

• XMLの構造は、XML Schema と同様の semantics を持つ何かにより定義されるでしょう。
• そして、ディフォルト値を保持するネストされた static なクラスで実装されるでしょう。
• ネストされたstaticなクラスはタイプセーフを実現します。
• また、特定の実装によりオーバライドされ、introspection が可能となります。
• そして、設定はJavaの中で閉じられます。

ネストされたstaticなクラスのsemanticsを拡張することを探究することは、XMLの設定の役割をannotationが提供するより、より厳密な方法で提供できると言及されています。

私もこの案は賛成です。ただし、中央集権的に扱うべき情報に対する実現案としては賛成です。しかしながら、中央集権的に扱うべき情報だけでなく、個々に扱うべき情報が存在するかと考えます。アノテーションのメリットを生かせる場面がないわけではないかと思います。

類似した考え方として、SpringのDependency Injection を設定ファイルではなく、上記同様Java のコードで実現しようとしたアプローチをご紹介されています。興味があるかたはご覧ください。

Examining the Validity of Inversion of Control
http://www.theserverside.com/articles/content/IOCandEJB/article.html

アノテーションに対する内省

Mike SpilleさんがアノテーションやIocに対する批評を述べられていましたが、私も少し考えてみます。

私はアノテーションの技術自体に対しては賛同しますが、アノテーションの乱用は好ましいとは考えておりません。
EJB3.0のように、アノテーションを用いソースコード中に全てを記述することは、同一の責務を持つ情報の分散に繋がるため、最善の方法だとは思えません。アノテーションを使用せず設定ファイルを用い実現するほうが、より最良である場合もあるかと考えます。
また、静的に(コンパイル時に)問題の有無を判断可能な仕掛けではなく、動的(実行時)に問題が顕在化する仕掛けである点も議論の余地が残ると考えています。この点に関しては、アノテーションを使用せず設定ファイルを使用した場合にも、同様の問題は残るかと思います。StrongTypingのように全てを静的にチェックすることが必須とはいいませんが、静的にチェック可能な部分に関してもそれを怠っている点があるのではないでしょうか。IDEのplugin等でのvalidationが１つの回避法であるとは思いますが、syntaxのチェックは可能でも semantics のチェックは難しいと考えます。

目的を実現することが目的ではなく、手段(新技術)を使用することが目的になっているような気がしてならない今日この頃です。

いつannotationを使用すべきか？

• 適用しようとしているメタデータがクラスのデザインを変更する場合
• メタデータがあなたのクラスと相互作用をおこなうコードのデザインを変更する場合
• アプリケーションサーバやデータベースの間のポータビリティを確保する必要がある場合、annotationを使用することは避けてください。
• deploymentごとに構成したいのであればXMLの使用を検討してください。