AdapterパターンとFactory Methodパターンの事例

2009年5月15日(金)
中川 三千雄

具体的なインスタンスの生成をサブクラスに委ねる

 Adapterパターンを適用したことで、log4jやJDK Logging APIなどのフレームワークを意識することなく、ログ出力の実装ができるようになりました。しかし、現状のままではAdapter役のクラスのインスタンスを明示的に生成する必要があります。

【利用例3-A】
Log logger = new Log4JLogger (Person.class); ……(1)
logger.info(“Adapter Pattern”);

 【利用例3-A】のようにAdapter役のクラスを明示的に生成したのでは、ロギングフレームワークへの依存が強くなります。例えば、何らかの理由でlog4jからJDK Logging APIに切り替える場合、(1)の実装をJdk14Loggerクラスに修正しなくてはいけません。これではAdapterパターンの効果も半減してしまいます。

 明示的なインスタンスの生成を行いたくない場合、図3-1のようにFactory Methodパターンを適用したLogFactoryクラス、LogFactoryImplクラスを用意します。

 Creator役であるLogFactoryクラスのgetLogメソッド(ファクトリーメソッド)で「Logインターフェースを持つクラスのインスタンスを生成する仕組み」を定めます。そしてConcreteCreator役であるLogFactroyImplクラスに具体的なクラス(Log4JLoggerクラス、Jdk14Loggerクラス、LogKitLoggerクラスなど)の決定を委ねます。

【利用例3-B】
Log logger = LogFactory.getLog(Person.class):
logger.info(“Adapter Pattern”);

 【利用例3-B】や図3-2を見て分かるように、Factory Methodパターンを適用したことでログ出力の実装からロギングフレームワークに対する依存がなくなりました。

■Commons Loggingに関する補足
 Creator役のLogFactoryクラスは、サブクラスであるConcreteCreator役のLogFactoryImplクラスのインスタンスを初期状態で生成し、保持しています。LogFactoryクラスのgetLogメソッドは保持しているLogFactoryImplクラスのgetInstanceメソッドによってクラスを決定してインスタンスを生成/取得しています。その生成ルールは次の通りです。

【生成ルール】
 1)プロパティファイルで指定されているクラスのインスタンスを生成する
 クラスパスの通った場所に[commons-logging.properties]ファイルがある場合、そのファイル内のorg.apache.commons.logging.Logプロパティで指定されているクラスのインスタンスを生成する。
 2)システムプロパティファイルで指定されているクラスのインスタンスを生成する
 システムプロパティファイル内のorg.apache.commons.logging.Logプロパティで指定されているクラスのインスタンスを生成する。
 3)log4j用のロガーのインスタンスを生成する
 クラスパスの通った場所にlog4jが置かれている場合、log4j用のロガーのインスタンスを生成する。
 4)JDK Logging API用のロガーのインスタンスを生成する
 動作環境がJDK 1.4以降の場合、JDK Logging API用のロガーのインスタンスを生成する。
 5)SimpleLog用のロガーのインスタンスを生成する
 commons loggingに含まれるSimpleLog用のロガーのインスタンスを生成する。

 一般的なFactory Methodパターンであれば次のようなソースコードになりますが、このような仕様のため、【利用例3-B】のようにLogFactoryImplクラスを明示的に生成することなくロガークラスのインスタンスを生成できるのです。

LogFactory factory = new LogFactoryImpl():
Log logger = factory.getLog(Person.class):
logger.info(“Adapter Pattern”);

AdapterパターンとFactory Methodパターンはいい関係

 今回紹介したcommons loggingは、AdapterパターンとFactory Methodパターンをうまく組み合わせて活用した良い事例です。Adapterパターンは似ている機能を持つクラスのインターフェースを変えることなく、利用者が望む別のインターフェースに変換して利用するパターンです。ロギングフレームワークのAPIは、このパターンにピッタリでしたね。

 一方、Factory Methodパターンはインスタンスを生成する仕組みとインスタンスを決定する仕組みを分けるパターンです。今回紹介したcommons loggingのインスタンスを決定する仕組みは多少複雑でしたが実行の直前にインスタンスを決定する仕組みの1つとして参考になったはずです。

 次回はcommons chainを事例にCompositeパターンとCommandパターンを紹介します。それでは、次回をお楽しみに!


【参考文献】
Erich Gamma, Rechard Helm, Ralph Jonson, John Vlissides『オブジェクト指向における再利用のためのデザインパターン』ソフトバンククリエイティブ(発行年:1999)

結城 浩『Java言語で学ぶデザインパターン入門』ソフトバンクパブリッシング(発行年:2001)

坂田 健二『Jakarta Struts逆引き大全333の極意』秀和システム(発行年:2004)

「Apache Commons - commons logging」(http://commons.apache.org/logging/)(アクセス:2009/04)

株式会社オージス総研
株式会社オージス総研アドバンストモデリングソリューション部アーキテクトチーム兼エンタープライズオープンソースセンター所属。これまでに2社の独立系SI企業で経験を積み、現在に至る。オージス総研では、フレームワークの設計/開発や開発プロセス支援など、アーキテクトとしてプロジェクトに参画する。また、オージス総研のコミュニティー「オブジェクトの広場」にも参加している。
オブジェクトの広場 http://www.ogis-ri.co.jp/otc/hiroba/

Think ITメルマガ会員登録受付中

Think ITでは、技術情報が詰まったメールマガジン「Think IT Weekly」の配信サービスを提供しています。メルマガ会員登録を済ませれば、メルマガだけでなく、さまざまな限定特典を入手できるようになります。

Think ITメルマガ会員のサービス内容を見る

他にもこの記事が読まれています