AdapterパターンとFactory Methodパターンの事例
デザインパターンでフレームワークをラップする
前回はObserverパターンの事例を紹介しました。Observerパターンは、オブジェクトの状態の変化に応じてほかのオブジェクトに何らかの通知を行うパターンです。また、何らかの通知によってオブジェクト同士が強く依存してしまうことを避けたい場合や、通知するオブジェクトを1つに特定したくない場合に有効です。
今回はcommons logging 1.1.1（http://commons.apache.org/logging/）を事例に、GoFのデザインパターンであるAdapterパターンとFactory Methodパターンを取り上げます。
Adapterパターン（図1-1）は構造に分類されるパターンです。Adapterとは「適合させるもの」という意味です。互換性のないさまざまなインターフェースを持つクラス（Adaptee役）に修正を加えることなく、利用者が望むインターフェース（Target役）で利用できるようにAdapter役が変換します。Adaptee役を包み込むような形になることからラッパー（Wrapper）と呼ぶこともあります。Adapterパターンは、「継承」と「委譲」の2種類の実現方法がありますが、今回は「委譲」で説明します。
Factory Methodパターン（図1-2）は生成に分類されるパターンです。Factoryとは「工場」という意味ですので、何かを作ったり加工したりすることを連想するかもしれませんが、このパターンはCreator役のクラスのcreateメソッド（ファクトリーメソッド）からProduct役のインスタンスを生成することを定めます。ただし、具体的なインスタンス生成はCreator役のサブクラスであるConcreteCreator役のクラスに委ねます。
このパターンはインスタンスを生成するための仕組みとインスタンスを決定するための仕組みを分けて考えることができます。ちなみにCreator役のクラスのファクトリーメソッドは、第1回（http://thinkit.co.jp/article/925/1/）で紹介したTemplate Methodパターンを応用することが多いです。
commons loggingは、AdapterパターンとFactory Methodパターンによってlog4jのAPIやJDK 1.4以降のLogging API（以降、JDK Logging APIと略す）などの異なるロギングフレームワークを簡単に切り替えて使うことができる、汎用的なロギングAPIです。
今回はcommons loggingの中で、どのようにパターンが適用されているのか、どのような効果があるのかを分析して理解を深めていきましょう。
ログ出力を行うソースコードはロギングフレームワークに依存する
ロギングフレームワークの中ではThe Apache Software Foundationのlog4jが有名ですが、ほかにもいくつか存在しています。ロギングフレームワークはファイルやネットワークなどに対してログを出力する仕組みを提供してくれます。利用するフレームワークによって異なりますが、出力先や出力するログレベルを設定ファイルで細かく操作することができます。
システム開発では、運用やデバッグの目的でログ出力を行う必要が出てきます。ログ出力を行うソースコードはロギングフレームワークに依存します。何らかの理由でlog4jからJDK Logging APIに切り替える場合、ソースコードに手を加える必要があります。
また、プレゼンテーションレイヤーや永続化レイヤーの汎用的なフレームワークを開発する場合では、利用するロギングフレームワークをあらかじめ決めたくはありません。なぜなら、そのフレームワークの利用者がロギングフレームワークを選択できなくなるからです。
もっとも良いのは、ロギングフレームワークを自由に変更できるようにすることです。そのためにはロギングフレームワークに依存しないログ出力のプログラミングを行う必要があります。
ロギングAPIの共通点を整理する
今回はlog4j、JDK Logging API、そしてAvalon logkitの3つのロギングフレームワークについてAPIの共通点を整理します。最初にそれぞれの利用例をご覧ください。
【log4jの場合】
import org.apache.log4j.Logger;
:
Logger logger = Logger.getInstance (Person.class);
logger.info(“Adapter Pattern”);
:
【JDK Logging APIの場合】
import java.util.logging.Level;
import java.util.logging.Logger;
:
Logger logger = Logger.getInstance (Person.class);
logger.log(Level.INFO, “Adapter Pattern”);
:
【Avalon logkitの場合】
import org.apache.log.Hierarchy;
import org.apache.log.Logger;
:
Logger logger = Hierarchy.getDefaultHierarchy().getLoggerFor(Person.class);
logger.info(“Adapter Pattern”);
:
ご覧の通り、細かな点を除くと利用方法には次の共通点があります。
1.ロガーのインスタンスを取得する
2.ロガーにエラーレベルとメッセージを指定してログを出力する
説明は割愛しますが、このほかにそれぞれのログレベルの有効／無効を確認するためのメソッドも実装してあります。
一方、異なる点は図2-1のようにログレベルの種類と数になります。ログレベルの種類と数を図2-1のcommons loggingの6種類のログレベルに合わせることで共通のインターフェースが見えてきます。
ロギングフレームワークをラップする
図2-1より、ロギングフレームワークに共通するLogインターフェースを定義します（図2-2）。さらにAdapterパターンを適用して利用者からそれぞれのフレームワークを切り離します。
log4jを例に説明するとLog4JLoggerクラスがadapter役になり、log4jのクラスがAdaptee役になります。Adaptee役を複数のオブジェクトで構成する必要がある場合は委譲の実現方法を選択します。Log4JLoggerクラスは、log4jのAPIをLogインターフェースに合うように変換して利用できるように実装します。
利用者はLogインターフェースを利用することで、ロギングフレームワークの種類を意識することなくログ出力の実装を行うことができるようになりました。
【利用例】
Log logger;
logger.info(“Adapter Pattern”);
今回はlog4jを例に説明しましたが、そのほかのロギングフレームワークもLogインターフェースに合わせることができれば、同様の考え方でログ出力の機能をラップして利用することができます。
具体的なインスタンスの生成をサブクラスに委ねる
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）
