Eyes, JAPAN Blog > Abstract Factoryパターン

Abstract Factoryパターン

makuta

この記事は1年以上前に書かれたもので、内容が古い可能性がありますのでご注意ください。

「abstract factory」を直訳すると「抽象的な工場」となります。

Factory Methodパターンは製品であるオブジェクトを作る「工場」を用意するパターンです。ここで見ていくAbstract Factoryパターンも同様にオブジェクトを生成するパターンの1つで、関連し合うオブジェクトの集まり、つまり部品の集まりを生成します。
ここで、「抽象的な」というところがポイントです。この工場は「抽象的」な工場で、生成される部品も「抽象的」なものになります。オブジェクト指向プログラミングでは、「ものを抽象化する」ということが重要なポイントとなります。つまり、具体的な物を直接扱うのではなく、「具体的な物を抽象化した物」を扱うということです。

Abstract Factoryパターンは、具体的なクラスを明確にすることなく、関連し合うオブジェクトの集まりを生成するパターンです。

データベースを使ったアプリケーションを構築する場合を考えてみましょう。
近年の開発・設計方法論では、データベースに関する処理内容とそれ以外のアプリケーション固有の処理とを分けて設計・実装することが主流になっています。なぜなら、接続やデータの取得、トランザクションなどデータベースだけに関する処理は、本来ビジネスロジックとは関係がないためです。
さて、データベースを使ったアプリケーションには、当然ですが何らかのデータベースが必要になります。しかし、プログラムを作成できても肝心のデータベースがないと動作しない、テストできないといった状況になりがちです。しかし、場合によってはデータベースが用意できないまま先行して開発を行わなければならないこともあります。

このような場合、データベースアクセスをすると見せかける擬似的なオブジェクトを使うと非常に有効です。このオブジェクトは「アクセスしているように見せかける」だけで、実際にはデータベースにアクセスしません。つまり、データベースがなくても、ビジネスロジック側を作成したりテストできます。
しかし、モックオブジェクトを使って開発した場合でも、最終的には実際にデータベースにアクセスするクラスに切り替える必要があります。
これはかなり大変な作業になります。しかし、ここでビジネスロジックを記述したコードを書き換えてしまっては再度テストをおこなわなければなりません。これでは何のためにモックオブジェクトを用意したのか分からなくなってしまいます。
データベースアクセスクラスの集まりを整合性を保ったまま簡単に切り替える・・・

このような場面でAbstract Factoryパターンが活躍します。

Abstract FactoryパターンのGoFでの定義は、
互いに関係したり依存し合うオブジェクト群を、その具象クラスを明確にせずに生成するためのインターフェースを提供する。
です。

Abstract Factoryパターンでは、部品の役割を持つクラスとその部品を作る工場の役割を持つクラスが存在します。

ただし、その工場には関連し合う部品を生成するためのメソッドがそれぞれ用意されます。また、関連し合う部品群の種類に応じて、その工場自身も「工場を生成するための工場」によって生成されます。
これにより、状況に応じて生成される具体的な部品群を切り替えることができます。

まとめると、Abstract Factoryパターンでは工場から生成される部品は抽象化されており、部品の具体的な内容や生成手順をクライアントが意識しなくて済むようになります。

Abstract Factoryパターンのメリットは、

・具体的なクラスをインスタンスから隠蔽する

・利用する部品群の整合性を保つ

・部品群の単位で切り替えができる

ということで、今回は

関連し合う部品群を生成するAbstract Factoryパターンについてでした。

  • このエントリーをはてなブックマークに追加

Comments are closed.