デザインパターンとは、システム設計におけるクラスやインターフェースの関係に名前をつけたものです。 GoFの23のパターンが有名です。デザインパターンというのは、どんなパターンなのか、パターンの目的は何かということを覚えることが非常に重要なのですが、これを実際に適用しようとした場合に、いつ適用していいかが見えてこないとお話になりません。

そこで、自分の勉強も兼ねつつ、パターンの実践時における使用場所や、パターンを適用するきっかけを見つけられるようにメモしておきます。

9回目は、抽象概念を用いて、関連オブジェクトの集合を作成するAbstract Factoryパターンのメモです。

Abstract Factoryパターン

Abstract Factoryパターンは、抽象化を用いて、関連オブジェクトの集合を作成するパターンです。

具象クラスを指定せずに、関連オブジェクトや従属オブジェクトの集合を生成するための規約を提供するのがこのパターンの目的です。抽象的な話だと、わかったようでわからないということになりかねないので、自分なりに具体的な例でまとめておきます。

僕の中で、Abstract Factoryパターンのイメージは、「Factory Method + ポリモーフィズム」だと思っています。Factory Methodパターンには、関連オブジェクトを自分の責務で生成するというものがありました。この目的で使うFactoryクラスを生成するFactoryがこのAbstract Factoryです。

つまり、関連オブジェクトを生成するFactoryの種類がたくさんあるので、Factoryを生成するFactoryを作った。それがAbstract Factoryだということです。このイメージで、Abstract Factoryパターンのクラス図を見るとわかりやすいと思います。

「OSFactory」がAbstract Factoryクラスになっていて、「WindowsFactory」、「MacintoshFactory」がそれぞれFactoryクラスです。

Abstract Factoryパターンは、今のようなOS毎に提供するリソースが違う場合に使われたり、GUIの生成時に使われたりします。JavaのAWTで使われているToolkitクラスはこのパターンが使われています。プラットフォームごとに実装が異なっています。

Toolkitでは、この他 Bridgeパターンの使われています。Abstract Factoryで生成した部品の実装をBridgeで管理して、プラットフォーム毎に異なる実装を隠しています。

パターンの適用タイミング

Abstract Factoryパターンの長所は、新たな実装を提供するのに柔軟性があるという点です。先ほどのOSの例だと、Factoryクラスに「UnixFactory」クラスが増えても、開放・閉鎖原則は守られています。

逆に、Abstract Factoryパターンの欠点は、関連オブジェクト(先ほどの例だと「ブラウザ」「ファイルシステム」)の種類が増えた場合、修正箇所がすべてのFactoryクラスに及んでしまう点です。この場合だと、開放・閉鎖原則は守られていません。Abstract Factoryインターフェースを適切に定義しておく必要があるということです。

関連オブジェクトが複数あり、生成の責務を自分が持つ場合リソースの関連に対して、複数の実装がありえる場合。これらの場合に、Abstract Factoryパターンが使えると思います。

実装サンプルと参考文献

Abstract Factoryパターンの実装方法をもっと詳しく知りたい場合は、下記のサイトにアクセスするのをお勧めします。もしくは、参考書籍を載せておきますので、そちらをお買い求めください。(^^;


  • 独習シリーズのデザインパターン編。デザインパターンを一人でも学べます。

  • Sun Microsystemのお墨付き。GoF以外のパターンも学べます。

  • UMLを使って、オブジェクト指向のいいとこ取りができます。

  • デザインパターンだけではなく、ソフトウェア設計の原則やプラクティスまで学びたい人におすすめ