読者です 読者をやめる 読者になる 読者になる

GoFの23パターンをまとめてみた

振る舞い

TemplateMethod
利用方法は固定、カスタマイズさえできればよい

呼び出し部分だけpublicにしてそこから呼び出す

継承してカスタマイズ部分を記述するだけ

再利用がしやすくなる

Iterator
データ構造の管理が複雑

管理クラスを作る

統一的なアクセス手段を提供できる

利用側がわかりやすくなる

Command
タイミングだけがわかっていて,具体的な内容が不定

コマンドを1つずつカプセル化

コマンドにが1つのオブジェクトになる

命令を集合として扱うことが可能に

State
状態遷移が複雑

状態を一つのクラスにして,クラス内で切り替える

複雑な条件分岐が減る

クラスは増えるが冗長性が消え,保守性は増す

Observer
状態の変化を通知させたりしたい

登録,解除を行うSubjectと,通知を受け取るObserverを作成

イベント駆動型プログラミングが可能になる

ObserverとSubjectの結合強度が減る

Strategy
アルゴリズムを状況に応じて選択したい

アルゴリズムをカプセル化する

複雑な条件分岐が減る

クラスは増えるが冗長性が消え,保守性は増す

Mediator
複数のオブジェクトが相互の作用している

まとめ役クラスを作る

各クラスはMediatorにのみ依存する

結合強度が減る

Visitor
新たな操作を構造を変更せずに既存のオブジェクトに追加したい

オブジェクト内のacceptメソッドで,Visitorのvisitメソッドに自分を渡して委譲する

アルゴリズムがオブジェクトの構造から分離される

アルゴリズムはVisitorによって多態的になる

Memento
カプセル化したまま状態を記録・復元できるようにしたい

オブジェクトが保持しているデータをそのオブジェクトだけがアクセスできるオブジェクトに保存

メモするときに作って,必要なときに開封するための専用クラスができる

一時的なセーブロードが可能になる

Interpreter
問題の解決手段として,規則の順序的な組み合わせを利用したい

規則や規則の集まりをオブジェクトとして表現する

規則がカプセル化される

追加や修正が容易になる

生成

Singleton
複数生成してしまうとまずいオブジェクトがある

オブジェクトの生成数を構造として制限する

生成側で今作られているオブジェクトを数える必要がない

生成側では何も考えずに作ってよい

使用例
通信のソケット

FactoryMethod
同じオブジェクトの生成の手順がいろいろなところにある

生成手順を1箇所にまとめる

生成する側は生成手順に依存しないコードを書ける

もし生成手順を変更する必要があったとしてもFactoryMethodのみの変更で済む

AbstructFactory
同じ手順で変化のあるものを生成したい

FactoryMethodを抽象化する

Factoryを切り替えるだけで生成されるオブジェクトも変わる

同じ手順で多様な生成が可能

使用例
GUIツールキット

Builder
アルゴリズムが複雑でスパゲッティ状態

生成部分と生成のアルゴリズム部分を分離

カプセル化できる

それぞれに集中できるので高機能にしやすい

Prototype
コピーがめんどい

自分をコピーして返す関数を作成

コピー元を引数にして生成

コピーが簡単

構造

Composite
似たような機能を持つクラスがたくさん

同一のインタフェースのノードにする

容器と中身を同一視できる

木構造を伴う再帰的なデータ構造を表すことができる

※一般化が過度になり,論理的に正しくない構造ができてしまうときがある

Adapter
インタフェースが違うが似た機能のクラスがある

インタフェースの違うクラスを継承し,さらに適応させたいインタフェース実装する

インタフェースを変えるだけのAdapterクラスができる

違うインタフェースのクラスもポリモーフィズムを使える

Facade
サブシステムが複雑

サブシステムの窓口クラスを作る

関連するクラス群が隠蔽される

サブシステムへの結合強度や依存性が減る

Proxy
外部のAPIやリソースに影響を受ける部分がある

代理のオブジェクトを介するようにする

高機能化を行うべき適切な場所が

元の本質的な動作を行う部分に変更を加えずに済む

Bridge
直列的に継承していくと,m*n*...個のクラスが必要

拡張する側で拡張元の参照を保持し,機能を参照先へ移譲する

拡張元が決定されなくなった

クライアント側で拡張の組み合わせを選ぶことで,m*n*...種類のオブジェクトが生成できる

Decorator
機能の拡張を柔軟にしたい

同じインタフェースで拡張する側で拡張元の参照を保持し,機能を参照先へ移譲する

拡張元が決定されなくなった

クライアント側で拡張の組み合わせを再帰的に選べるようになる

Flyweight
何度も同じリソースを生成するのは無駄

プールを作って,存在すれば既存のオブジェクト,存在しなければあたらしいオブジェクトを返す

オブジェクトを容易に使いまわせるようになる

オブジェクト生成のオーバーヘッドが減少