GoFデザインパターンはなかなか奥深く、入門書を読んでパターンごとのクラスの絡み合いを理解しただけでは 真価を理解できないことが多々あります。
独習デザインパターン のクラス図からAbstract Factoryパターン と Builderパターンの違いがうまく説明できなかったので GoF本を紐解いて その目的を調べてみました。

Abstract Factoryパターンの適用可能性

Abstract Factoryでは、「ある抽象的な型の実装を返す」というインターフェースを定義し、 そのインターフェースの実装を多種揃えるといった形になります。

GoF本では例としてlook&feelを取り上げています。 JavaのswingのライブラリではUIのデザインをごっそり切り替えることができますが、 その具象クラスの生成を具象型を知らずに行いたいというようなケースを想定すればよいのでしょう。

GoF本では適用可能性に以下をあげています。

Abstract Factory パターンは、以下のような場合に有効である。

• システムを部品の生成、組み合わせ、表現の方法から独立にすべき場合。
• 部品の集合が複数存在して、その中の１つを選んでシステムを構築する場合。
• 一群の関連する部品を常に使用しなければならないように設計する場合。
• 部品のクラスライブラリを提供する際に、インターフェースだけを公開して、実装は非公開にしたい場合。

look&feelは２番目の条項ですね。look&feelの例からすると、 多数のクラス群をごっそり切り替える場合にAbstract Factory パターンを適用するのが分かります。

Builderパターンの適用可能性

Builderパターンでは「多くの構成要素からなるオブジェクトを組み立てるための部品を返す」インターフェースを定義します。 そしてこの実装を多種揃えることになります。
この部分のクラスだけを見ているとAbstract Factoryとなんら変わらないように見えたのです。

決定的な違いは、Abstract Factoryが呼び出し元となるクラスを特定しておらず、 メソッドの呼び出しに応じて完成品を返すということ。
BuilderはDirectorと呼ばれる特定のクラスからの呼び出しを期待しており、 一個の完成品を返すというよりも、それを組み立てるためのパーツを返すという点。 完成品となるオブジェクトはDirectorクラスが不特定多数のクラスの呼び出しに応じて返すことになります。

この目的というか適用部分を把握するとなるほど目的が違うことがはっきりわかります。 GoF本では適用可能性として以下を挙げています。

Builder パターンは、次のような場合に適用することができる。

• 多くの構成要素からなるオブジェクトを生成するアルゴリズムを、構成要素自体やそれらが どのように組み合わされるのかということから独立にしておきたい場合。
• オブジェクトの作成プロセスが、オブジェクトに対する多様な表現を認めるようにしておかなければならない場合。

GoF本への回帰

GoFデザインパターンを解説した本は数ありますが、GoFの23個のパターンすべてを網羅しているにもかかわらず そのページ数がGoF本のそれと大して変わらないものが多くあります。(GoF本が412ページ)

それらの本では、オブジェクト指向の扱い方についての説明に終始しているものが多く、 コードレベルでどうなっているか、そこに使われるオブジェクト指向のテクニックは何か、 そのあたりをターゲットにしているように思います。

一方の本家であるGoFは、あくまで「デザインパターン」の本であり、 そんな細かいテクニックは当然知っている前提で、どのように設計するのかという視点で書かれています。

デザインパターン入門書の類の説明では設計にどう生かすのか分らないと思ったらGoFを紐解きましょう。 入門書ではカットされたエッセンスがそこには詰まっています。