アノテーションでデザインパターンの役割をマークする (1)：パッケージ・ベース

今回は「アノテーションでデザインパターンの役割をマークする」ための一番素直な実現、「パッケージ・ベースの実現」。　これは、1つのデザインパターンをマーキングするのに必要なアノテーションを1つのパッケージにまとめます（うーむ、当たり前？）　当然、パッケージ名をパターン名に。

アノテーションの実装

前回、サンプルコードを載せた「サービスプロバイダーフレームワーク」に対してマーキングをするアノテーションを実装しましょう。　必要なアノテーションは

• サービスインターフェース (@service)
• サービスプロバイダーインターフェース (@provider)
• プロバイダー登録 API (@ProviderRegistration)
• サービスアクセス API (@ServiceAccess)

でした。　@service, @provider は1文字目が小文字になってますが、これはサンプルで用いるインターフェースとの名前の衝突のためで、本質的ではありません。　通常開発するのインターフェースに Service, Provider のような一般的な名前は付けないと思うので（付けてたらやめましょう）、特に問題はないと思います（単にサンプルとして持ってきたコードが悪かっただけ？）。

パッケージ名は「service_provider」にしています。　別に「annotation.designpattern.service_provider」のようなものでもいいかと思いますが。

service_provider/service.java

package service_provider;

@Documented
@Target(ElementType.TYPE)
public @interface service{}

service_provider/provider.java

package service_provider;

@Documented
@Target(ElementType.TYPE)
public @interface provider {}

service_provider/ProviderRegistration.java

package service_provider;

@Documented
@Target(ElementType.METHOD)
public @interface ProviderRegistration {}

service_provider/ServiceAccess.java

package service_provider;

@Documented
@Target(ElementType.METHOD)
public @interface ServiceAccess {}

役割を見るのがとりあえずの目的なので、@Documented を付加して JavaDoc に載るようにしてます。

アノテーションの使用

では、上記のアノテーションを使って、前回のサンプルに役割を付加してみましょう：

// Effective Java 第2版
// 『項目1　コンストラクタの代わりに static ファクトリーメソッドを検討する』より

@service
public interface Service {
    ...  // サービス固有のメソッドをここに
}

@provider
public interface Provider {
    Service newService();
}

public final class Services {
    ...
    @ProviderRegistration
    public static void registrerDefaultProvider(Provider p){...}

    @ProviderRegistration
    public static void registerProvider(String name, Provider p){...}

    @ServiceAccess
    public static Service newInstance(){...}

    @ServiceAccess
    public static Service newInstance(String name){...}
}

まぁ、こんなもんでしょう。

Effective Java 第2版 (The Java Series)

川口耕介氏の新連載『やっぱりJavaがスキ！』がスタート↓

WEB+DB PRESS Vol.50