対象に依存せずIterateできる。
Iterateの順序などカスタムできる。
既存Adapteeに一切手を加えずに流用できる。
既存クラスの使用さえ分かれば作れるし、再テストせずに済む。
親クラスで処理の枠組みを定め、サブクラスで実装する。
直接インスタンス生成せずFactoryのメソッドによってインスタンスを生成して返す。
インスタンス生成にTemplate Methodを使う。
特定クラスのインスタンスを1個に制限する。
N個に制限するなど応用もある。
インスタンスから別のインスタンスを作り出す。
複雑なインスタンス生成工程を省く。
複雑なインスタンスを、メソッドを用いて組み上げる。
Builderはサブクラスの組み立てに必要なメソッドを網羅する必要がある。
抽象的な工場と部品の組み合わせを定義して、具体的な実装を設計する。
ConcreteFactoryの追加は簡単。何を実装すればいいか明らか。
部品の追加は困難。関連する全ての向上を改修する必要がある。
機能のクラス階層と実装のクラス階層を分離して橋渡しする。
アルゴリズムの切り替え。同じ問題を別の方法で解く。
計算アルゴリズムや将棋のロジック切り替えなど。リソースや難易度などに応じる。
容器と中身を同一視し、再帰的な構造を作る。
ディレクトリの中にサブディレクトリやファイルがあるようなパターン。
中心となる機能に対して機能を付け加えてDecorateする。
Decorateされる中身を変更することなく、機能（Decorate)を追加できるが、クラスが増える傾向。
構造と処理を分離する。Directory内容を再帰的に訪問しながら処理する等。
処理種類の追加が容易。構造の追加は困難。構造クラスだけvisitを追加する必要がある。
処理できない要求がきたら次の処理にたらい回しする。
連鎖の順序や形態を変更可能。各処理を明確化・専門家できる。
複雑な処理をまとめて高レベルAPIとして窓口を提供する。
オブジェクト間の通信を一手に引き受け、状態管理などを統括する。
観察対象の状態が変化すると処理が実行される。というより、通知とそれに応じた処理。
状態変化に応じた処理を実装するときに有効。
状態を保存・履歴管理・復帰する。
管理対象からは内部状態が見える（同パッケージ）が、呼び出す側（Main）には見せない。
状態をクラスで表現する。
呼出す側は状態に応じてStateオブジェクトを切替、共通のメソッドを呼出すだけ。
同じインスタンスを複数生成しないようHashTableなどで制御する。
(簡単かつファイル容易が手間なので社協は割愛)
本命クラスにかわり、代理人が一部の処理を受け持つ。
重い処理などが本当に必要になった時初めて本体を生成し委譲する。
メソッド呼び出しではなく、処理自体をクラスとして表現して呼出す。
ミニ言語を作り、ミニ言語で機能を実装する。
Javaのバージョンなど環境変化に強い（改修箇所がミニ言語で実装した部分のみ)