デザインパターンのバイブル的存在GoF本

林田力

本書（エリック ガンマErich Gamma著、ラルフ ジョンソンRalph Johnson著、リチャード ヘルムRichard Helm著、ジョン ブリシディースJohn Vlissides著、本位田真一訳、吉田和樹訳『オブジェクト指向における再利用のためのデザインパターン　改訂版』ソフトバンククリエイティブ、1999年）は1995年に刊行された『Design Patterns : Elements of Reusable Object Oriented Software』の邦訳である。

著者の4人はGoF（Gang of Four; 4人のギャング達）と呼ばれる。彼らは有益なデザインパターンを持ち寄り、本書にまとめた。ここではオブジェクト指向で設計する者がその最適な解を求める上で当然の帰結として用いられる普遍的なデザイン23パターンを整理している。本書はGoF本とも称され、デザインパターンのバイブル的存在になっている。

デザインパターン（design pattern）は良い設計のためのノウハウ集である。過去のソフトウェア設計者が発見し編み出した設計ノウハウを蓄積している。オブジェクト指向ソフトウェアを設計する際に繰り返し現れる経験的な要素を抽出し、効率の良いプログラミングをするためのテンプレートになる。

デザインパターンはソースコードや再利用可能なコンポーネント等のような具体的なものではなく、良いオブジェクト指向の設計の見本というスタンスである。以前経験したことがある、似たような問題の解決法に分かりやすい名前を付けて、再利用しやすいように特定の規約に従ってカタログ（虎の巻）化した。

オブジェクト指向プログラミングにおいてデザインパターンを利用することは、開発者に様々なメリットを与える。ここでは2点ほど指摘する。

第一に再利用性の高い柔軟な設計が可能になる。設計者の直感や経験に依存していた設計から先人達の知恵を利用した設計になる。設計力の向上が期待でき、設計の品質も安定する。既存のシステムの文書化が容易になり、システムの保守性も向上する。

第二に開発者同士の意思疎通が容易になる。デザインパターンを習得している開発者同士であれば、「○○パターンでいこう」「××パターンが応用できる」で話が通じ、詳細な説明を省略できる。

デザインパターン適用にも注意点がある。デザインパターンは、あくまで「ある一つの問題に対する解決策」である。適したパターンを使用しなければ意味がない。そのためにデザインパターンの適用が余計なトラブルの原因になることもある。

本書で整理したデザインパターンは3種類に大別される。

第一に生成に関するパターンである。

Factory Method：サブクラスがインスタンスを生成する。オブジェクトを生成する時のインタフェースだけを規定して、どのクラスをインスタンス化するかはサブクラスで決定する。

Factory Methodではnewによるインスタンス生成をインスタンス生成のためのメソッド呼び出しに代替する。それによって具体的なクラス名による束縛からスーパークラスを解放する。

1つのファクトリは1つのオブジェクトの生成のみを行うため、生成するオブジェクトの種類の変更を行う場合、ファクトリクラスを切り替える必要がある。その結果、クラスの関連を複雑にするというデメリットがある。

Singleton：インスタンスの数を制限。クラスがインスタンスを１つだけしか持たないことを保証する。既に作成していればそれを渡し、一度も作成していなければ、新規作成後に渡す。

Builder：複雑なオブジェクトを生成。同じ生成過程で異なる表現形式のオブジェクトを生成する。様々なバリエーションでオブジェクトを生成するBuilderクラスと、複数のBuilderクラスをまとめて管理するDirectorクラスを用意する。

Prototype：原型からオブジェクトを生成。様々な種類のオブジェクトを大量に生成する。

Abstract Factory：抽象的な工場を使用する。互いに関連したり依存したりするオブジェクト群を、その中身のクラスを明確にせずに生成する。インスタンスの生成を専門に行うクラスを用意することで、整合性を必要とされる一連のオブジェクト群を間違いなく生成する。

第二に構造に関するパターンである。

Adapter：クラスの橋渡し役。既存のクラスに別のインタフェースの機能を持たせる。

Bridge：委譲を使って機能と実装を分離する。関連の強い２つのクラスを互いに影響しないようにした状態で拡張する。

Composite：再帰的に一連の操作を実行。階層構造をなすオブジェクト全体に、再帰的に一連の操作を実行する。全ての要素に共通の処理（Operation）を持つ抽象クラス（Component）を定義し、サブクラスとして複合要素（Composite）と単独要素（Leaf）を別々に用意する。

Decorator：クラスを拡張する。既存のインタフェースを変更せずに機能を追加する。

Facade：単純なインタフェースを提供。複数のインタフェースに１つの統一されたインタフェースを提供する。既存のクラスを複数組み合わせて使う手順を、窓口となるクラスを作ってシンプルに利用できるようにする。

Flyweight：オブジェクトを再利用。サイズの小さなオブジェクトを大量に生成する。

Proxy：あるオブジェクトへのアクセスを制御するため、そのオブジェクトの代理となるものを提供する。

第三に振る舞いに関するパターンである。

Chain of Responsibility：複数のオブジェクト間で処理要求を転送する。１つのリクエストを、オブジェクトのチェーン内のいずれかのオブジェクトで処理する。

Command：処理をコマンド化。リクエストをオブジェクトとしてカプセル化し、複雑なリクエストを処理できるようにする。

Interpreter：オブジェクトをいつでも元に戻せる。構文解析の結果を実行する。

Iterator：複数のオブジェクトを１つずつ順番にアクセスする。集約オブジェクトを生成するクラスが走査のための共通のインタフェースを与えるようにすることで、変更すべき点を少なく抑える設計になる。

Mediator：調停者が複数のオブジェクトを一元管理する。複数の部品オブジェクトを相互作用させる。

Memento：オブジェクトの変更履歴を管理する。オブジェクトの状態をいつでも元に戻せるようにする。

Observer：状態の変化を通知する。自分以外のオブジェクトの状態が変化したことをチェックし、他のオブジェクトに知らせる。

State：状態をクラス化する。あるオブジェクトの状態を異なるサブクラスに属する別々のオブジェクトとしてカプセル化する。オブジェクトの処理内容を状況に応じて切り替える。

Strategy：アルゴリズムの入れ替え。アルゴリズムの集合をカプセル化し、それらを交換可能にする。

Template Method：処理をテンプレート化。大きな処理を部分的に変更する。

Visitor：複数のオブジェクトを訪問する。処理を追加するクラスを変更せずに新しい処理を追加する。

 Loading ...