前回投稿後すぐに書き始めたのに途中で寝ちゃったおかげで結局この時間ですよ'`,､(´∀`)'`,､
ついにパターンのカタログまで来ました。今回は Abstract Factory パターンです。
Abstract Factory は何らかのインスタンスを必要とする時に、その実装に関わる具象クラスを明確にせずに生成する為のマネージャクラスを用意するパターンです。それなりに構造化された設計のプログラムなら、HogeManager とか HogeCreator 見たいなクラスがあったりするでしょう。そう言ったクラスは多くの場合 Abstract Factory を用いて設計されているのではないでしょうか。
このパターンは、抽象クラスとサブクラスを用いて場合によって実装をスイッチする際等に活躍します。本書に載っている例で言えば、複数の look-and-feel 規格に対応したアプリケーションを書く場合、実際に使用する look-and-feel に拠らないウィジェットクラスを書くために Abstract Factory を利用しています。
Abstract Factory を簡単にまとめると、何らかのオブジェクトの集合に対して複数の実装系がある時、生成用のアクセスポイントを持つマネージャクラスを用意し、実際の生成はサブクラスに任せる構造です。
例えば、複数のプラットフォームに対応したアプリケーションを書く場合、各プラットフォーム向けのＧＵＩコンポーネント群を定義するでしょう。その時、実装に拠らず同じオペレーションで同等の機能を呼び出す為に、各コンポーネントは抽象基底クラスから派生して実装するかと思います。しかし、生成する場面で特定の実装に触れたくないのです。Window* w = ComponentFactory::GetInstance()->CreateWindow(); で Win32 も Mac も X-Window もフォローしたいわけです。そこで生成の為のインターフェイスを持つマネージャクラスを用意し、それを派生して各実装のコンポーネントを生成するサブマネージャクラスを定義します。後はプラットフォームにあわせた具象クラスを抽象マネージャクラスに代入して、コンポーネントの生成は抽象マネージャクラスを通せばよいのです。また、Singleton パターンや Factory Method パターンとの併用も良く見られます。
ただし、パターンもいい事づくめと言う訳ではありません。メリットがあればデメリットもあります。AbstractFactory に関しては、インターフェイスの追加や削除を含む変更に弱いと言うデメリットがあります。インターフェイスの追加や削除が行われるとサブクラスまで手を加えなければなりません。この問題に関しては Andrei Alexandrescu が Modern C++ Design にて一つの解答を示しています。
生成に関するパターンはＣ＋＋に於ける不可避の定数性、詰まり new 構文でクラス名が既知でならなければならない問題を最小化します。これは動的に型付けする言語では問題にならないのかもしれませんが、静的な型付けを行う言語ではまず確実に問題になる部分です。長月はＣ＋＋ぐらいしかまともなＯＯＰＬに触れていないので他の言語の事情を知りませんが、生成に関するパターンはＣ＋＋でそれなりに良い設計と実装を行いたければ必須の構造に思えます。
今回はそれらの生成に関するパターンの中で、Singleton や Factory Method 等の小さい粒度のパターンを除けば最も頻出するであろう Abstract Factory を紹介しました。本エントリで Abstract Factory に興味を持たれた方、是非本書や増補改訂版Java言語で学ぶデザインパターン入門等でデザインパターンを勉強してみては如何でしょうか？