クラス図説明

Iterator パターン

目的	Listのような集合オブジェクトの各要素に順次アクセスする方法の実装を外部クラスに委譲
クラス図

各役割の説明へ

Adapter パターン

目的	インタフェースに互換性の無いクラス同士を組み合わせることを目的としたパターン 継承を利用した手法と委譲を利用した手法が存在 クラスによるAdapterパターン (継承) インスタンスによるAdapterパターン (委譲)
利用シーン	既存のクラスを再利用して、必要とするクラスを作成する場合 (既存のクラスが十分テストをされているなら、再テストのコストも削減できる。 バグが出たとしても既存クラスのバグである可能性は低いためデバッグが容易)
クラス図:継承

各役割の説明へ

Template Method パターン

目的	ある処理のおおまかなアルゴリズムをあらかじめ決めておいて、そのアルゴリズムの具体的な設計をサブクラスに任せること
メリット	スーパークラスのテンプレートメソッドで大きな流れが記述されるので サブクラス側で流れ記述する必要がなく、具体的な肉付けのみ記述すれば良い ＊ あまりに継承を複雑化してしまうとコードを追いにくくなるので、継承は1階層ぐらいに留めておくべき
クラス図	AbstractClass で定義されている抽象メソッドの可視性が protected なのは このメソッドが AbstractClass#templateMethod() 内でのみ使用されることを想定しているため

各役割の説明へ

Factory Method パターン

目的	生成するインスタンスの種類が多くなりそうな場合に、 インスタンス生成の責務を外に切り出して保守性を高める (オブジェクト生成を疎結合化) オブジェクトを生成する際のインタフェースだけを規定し、実際にどのクラスをオブジェクト化するかはサブクラスにまかせる。
メリット	オブジェクトの生成処理と使用処理を分離し、利用者側から隠すことでクラス間の結びつきが低くなる。 これにより、再利用性が高まり柔軟な対応が可能となる。 インスタンスの生成の前や後に色々な処理をやる必要がある場合、それをクライアント側ではなく、Factoryクラス側 クライアント側は生成するオブジェクトの生成過程まで気にする必要はなく、メインロジックに気を使えばよい。 オブジェクトの生成過程に変更が入ったとしても、クライアント側を修正する必要はない。
クラス図

各役割の説明へ

Singleton パターン

目的	そのクラスのインスタンスが1つしか生成されないことを保証
メリット	インスタンスを使いまわすことにより負荷を軽減 扱い次第では、グローバル変数のように機能させることもできる (グローバル変数と同様の問題を引き起こす危険性をはらむ→どこで値が書き換わるか予測できないなど → パッケージ指定により問題を軽減)
注目点	同じ型のインスタンスが private なstaticフィールドとして定義 コンストラクタの可視性が private 同じ型のインスタンスを返す getInstance() がクラス関数として定義
クラス図
Singleton	唯一のインスタンスを得るためのstaticメソッドを持つ このメソッドは常に同じインスタンスを返す

Monostateパターンの説明へ

SingletonパターンとMonostateパターンの違いへ

Prototype パターン

目的	「原型」となるインスタンスから新しいインスタンスを生成するパターン (Prototype ： 「模範」「原型」)
メリット	多くなりすぎたクラスの管理が容易になる (生成オブジェクトを同一クラス(Prototype) のインスタンスにすることができる為) 生成の複雑なインスタンスをコピーできる フレームワークと生成するインスタンスを分けられる オブジェクトの生成処理を隠蔽できる クラス同士の関係を緩くする
利用シーン	インスタンスをコピーして処理を変更したい場合 複雑な生成過程を経たインスタンスをコピーしたい場合 テンプレートインスタンスをコピーすることで処理が楽になる場合
クラス図

注意点等へ

各役割の説明へ

Builder パターン

目的	インスタンス生成手順が複雑な場合やインスタンス生成構成が複雑な場合に生成を簡略化
メリット	同じ作成過程で異なる表現形式の結果を得られる Productオブジェクトの生成過程や生成手段を隠し、局所化できる
Template Methodパターン との違い	インスタンス生成の役割を誰が負うのかというところ Builder Directorクラス(他のクラス) Template Method スーパークラス
クラス図

各役割の説明へ

Abstract factory パターン

イメージ図、クラス図へ

各役割の説明へ

Bridge パターン

目的	機能のクラス階層と実装のクラス階層を別々に管理し結びつける(橋渡しする)パターン。クラスを複数の方向に拡張させることを目的とする。
クラス階層	機能のクラス階層 スーパークラスは基本的な機能を持ち、サブクラスで新しい機能を追加するクラス階層 実装のクラス階層 スーパークラスは抽象メソッドによりインターフェースを規定し、サブクラスは具象メソッドによりインターフェースを実装
利用シーン	あるプログラムにOS依存の部分があり、Windows版、Mac版、UNIX版に分かれている場合 OS依存の部分を "実装のクラス階層" で表現し、"機能のクラス階層" に機能を追加する
クラス図

各役割の説明へ

Strategy パターン

目的	アルゴリズムの部分をカプセル化することで、アルゴリズムを動的に切り替えることができるパターン アルゴリズムを使用者から独立したまま様々に変化させることができる Strategy = 「戦略」 を意味する言葉
メリット	アルゴリズムをカプセル（クラス）化できる アルゴリズムの拡張性と保守性を高め、再利用を可能にする アルゴリズムを切り替えるクラスとは無関係になる アルゴリズムの実行にインタフェースを使用する インタフェースが提供するのは、操作（メソッド）の窓口だけ (「関心の分離」)
利用シーン	元のアルゴリズムを改良したアルゴリズムの速度を比較したい場合 ゲームの難易度に合わせて、戦略アルゴリズムを変える場合 動作環境に応じて処理を変えたい場合 * 継承を使用してアルゴリズム処理の差分を実装しているような処理や switch文、if文などの分岐処理を多用しているようなクラスが存在する場合にも採用を検討
クラス図

各役割の説明へ

Composite パターン

目的	単一のオブジェクトとその集合のどちらも同じように扱えるようにするためのパターン ディレクトリとファイルなどのような、木構造を伴う再帰的なデータ構造を表す Composite ： 意味 - 混合物、複合物
メリット	登場するオブジェクトは、「枝」と「葉」で、共通のインターフェースを実装している。 そのため、枝と葉を同様に扱うことができる (同じAPIでアクセスできる)。 木構造の枝葉を同一視する事ができるため、新しい枝（Compositeクラス）を簡単に追加出来る。 ＊データ構造がきちんと木構造を保つようにしなければ、親子関係が循環してしまった場合 Component#operation() を実行した際に無限ループに陥ってしまう。
利用シーン	ファイルシステムのディレクトリツリーのように、木構造を持つデータ構造
クラス図

各役割の説明へ

Decorator パターン

目的	既存のオブジェクトを新しい Decorator オブジェクトでラップするパターン
メリット	飾り枠と中身を同一視することで機能拡張がより柔軟にできる (飾り枠と中身が同一のインタフェースを持つ) オーバーライドせず、委譲を活用して振る舞いを装飾（拡張）できる 既存のオブジェクトに新しい機能や振る舞いを動的に追加できる 付加する機能が複数ある場合、それらを任意の順番で組み合わせることができる
デメリット	Decoratorパターンでは、すべてのクラスが同じインターフェースを持ため 具体的なクラスを後で1つ追加しようとした際、メソッドに引数を増やす必要が生じたり メソッドが投げる可能性のある例外が増えることにより これまでに作ったDecoratorも含め、すべてのクラスを修正しなくてはならない。 多数の小さなクラスができる可能性があり、乱用すると複雑になる可能性がある。 Decoratorパターンは機能を細分化し、たくさんのクラスに分割できる点が特徴であるため、クラスの数が多くなる。 一般にインターフェースの変更は影響が大きいが、Decoratorパターンでは特に修正範囲が広くなりやすい。
クラス図

各役割の説明へ

Visitor パターン

目的	データ構造と処理を分離するパターン
メリット	処理を構造から切り分けることで、処理は処理クラスの中に閉じ込め、処理の追加や変更に対する自由度を高めることができる 処理内容に変更があった場合は、ConcreteVisitorクラスを変更するだけでいい。 (ConcreteElementのクラスを変更しなくていい) 新しい処理を追加したくなった場合は、Visitorクラスを継承した新しいクラスを作ることで対応できる。
デメリット	ConcreteElement役の追加は困難。 Element役はVisitor役に対して十分な情報を公開する必要があるが公開すべきでない情報を公開してしまうと、カプセル化が壊れたクラスになってしまう。
クラス図

各役割の説明へ

Chain of Responsibility パターン

目的	複数のオブジェクトを鎖状に繋ぎ、あるオブジェクトが要求を処理するまで、チェーンに沿って要求を渡していくパターン。 (Chain of Responsibility =「責任の鎖」=「責任」を負ったものが、「鎖」状につながれた状態)
イメージ
メリット	要求側（Client）と処理実行側（ConcreteHandler）の結びつきが緩やかになる。 要求側（Client）で「どのオブジェクトに処理を行わせるか」ということを意識する必要がない。 新しい処理クラス（ConcreteHandler）を簡単に追加できる 動的に処理チェーンを変更できる 各クラスが責任を持つことで、各クラスの責任を明確にし処理に集中できる。
デメリット	処理が遅くなる可能性がある。 (適切な処理を行うConcreteHandlerを順次探さなければならないため)

クラス図、各役割の説明へ

Facade パターン

目的	複雑な処理を簡単に呼び出すことを目的としたパターン ファサード(仏) = 「建物の正面」の意 サブシステムに対する明確で簡潔なインタフェースを定義し、使いやすいようにその内部構造を隠蔽
メリット	あるAPIを呼び出すだけでサブシステムを利用できるようになる (複雑なものを単純に利用できる) クライアントとサブシステム、サブシステム同士の依存関係が緩くなる
ポイント	Facedeパターンはサブシステムの直接使用を妨げない。 Facedeクラスの利用は強制ではなく、必要であればサブシステムの機能を直接利用できる。 Facadeパターンでは処理の呼び出し口となるメソッドはstaticメソッド(クラスメソッド)として定義される インスタンス化不要でメソッドの呼び出しができるので、ユーザは楽になる。 Abstract Factory パターンは Facade パターンの具体例と言える。 ConcreteFactory クラスが Facade クラスに相当。
クラス図

各役割の説明へ

Mediator パターン

目的	クラスの複雑なやりとりを一極集中するためのパターン (Mediator : 「仲裁人、調停者」の意) 複雑に絡み合った複数のオブジェクト間の関係を、必ず「仲介者」を介して処理を行う様にすることで単純かつ明快なインタフェースを提供
メリット	通信するオブジェクト同士の依存関係を削減(お互いに直接的な参照をさせない)し、結合の度合いを低くする コントロールロジックは相談役の中にのみ記述される為、デバッグ・修正がしやすい。 処理が一箇所に集中されるため、不明瞭になりがちなオブジェクト同士の関係が明確になる
利用シーン	複雑に絡み合う、多数のオブジェクト間の調整を行いながら処理をすすめる必要がある場合 GUIアプリケーションで特に効果的
Facadeパターン との違い	Façade Façade役が一方的に他の役を利用して高レベルなインターフェース (API) を作る (一方向) Mediator Mediator役がColleague役の仲介者としてやりとりを行う (双方向)
クラス図

各役割の説明へ

Observer パターン

目的	インスタンスの状態が変化した際、そのインスタンス自身が、「観察者」に状態の変化を「通知」する Observer = 「観察者」 「観察者」は能動的に観察するのではなく、インスタンスから「通知」されるのを受動的に待っていることになる為 Publish-Subscribeパターンと呼ばれることもある (Publish = 「発行」、Subscribe = 「購読」)
メリット	状態が変化する側が「通知」する仕組みを持つことで、観察者は常に観察しなければいけない状態から開放される
利用シーン	ユーザーが何らかの操作をするなどの外部イベントを待つ場合 オブジェクトの属性値の変化を待つ場合 Model View Controllerパラダイムの実装に使われることも多い MVC では、モデル・ビュー間のループに Observer パターンが使われる 通常、モデルの変化を引き金として、ビュー（オブザーバ）にそれを通知する
クラス図

updateの呼び出しパターンへ

各役割の説明へ

Memento パターン

目的	インスタンスの状態を表す役割を導入して、カプセル化の破壊に陥ること無く保存と復元を行う
カプセル化の破壊	不用意に内部情報へのアクセスを許したため、そのクラスの内部構造に依存したコードがプログラムのあちこちにちらばりクラスの修正がしにくくなる状態
利用シーン	テキストエディタやペイントソフトのように、操作をキャンセルして元の状態に戻す 「アンドゥ」機能などを実装したい場合 Memento ： 英語で「記念品」「形見」を意味 Mementoパターンを利用すると undo (やり直し) redo (再実行) history (作業履歴の作成 snapshot (現在状態の保存) などを行うことが出来る。
クラス図

各役割の説明へ

State パターン

目的	状態をクラスとして表現しクラスを切り替えることにより状態の変化を表すパターン。(状態に応じて振る舞いを変える必要がある場合に有効) (「クラスの変化＝状態の変化」)
ポイント	状況（Context）に状態 (State) オブジェクトを保持し、状態による個々の振る舞いは派生クラス(ConcreteState)で実現
メリット	条件(状態)に一致するか否かの処理は、条件分岐でも同じことを実現できるが、処理が複雑になったり、その状態の数が多い場合は後々の管理が大変になる。 状態をクラスとして表現することにより、上記問題が解消される。 また、状態を表す変数が1つのため、自己矛盾が起こらない。
クラス図

各役割の説明へ

状態遷移の方法へ

Flyweight パターン

目的	生成済みのオブジェクトを共有することで、リソースを無駄なく使うこと
メリット	同じオブジェクトを再利用することでメモリの使用量を抑え、インスタンス生成の処理を省き、効率的な処理になる 利用者側が得る結果は(再利用・新規生成問わず)全く同じであるため、利用者は内部構造を意識せずに使うことが出来る
注意点	一度 FlyweightFactory に保存されたインスタンスは、不要になってもガベージコレクションの対象とならない。 (明示的にインスタンスへの参照を削除)
利用シーン	軽量化対象のクラスが, 不変なクラス (イミュータブル, immutable なクラス) の場合。 (共有しているものを変更すると複数箇所に影響が及ぶため) 不変なクラス・・・オブジェクトが生成された後、その状態が変化しないクラス (フィールド値が不変)
クラス図

各役割の説明へ

Proxy パターン

目的	身代わりとなるオブジェクトを通じて間接的に目的のオブジェクトにアクセスさせるためのパターン
メリット	オブジェクトとその利用側との間に緩衝剤を用意することで、お互いを分離したり付加的な機能を追加できる 分離するということは、具体的なクラスに依存しないコードになる ProxyクラスとRealSubjectクラスは、どちらもSubjectインターフェース (API) を実装している為 必要なければRealSubjectを直接呼び出すこともできる
Decoratorパターン との違い	Decoratorパターン 機能の追加が目的 クラスを作る人の目線 Proxyパターン 呼び出す利用側が簡単に扱えることが目的 クラスを使う人の目線
クラス図

各役割の説明へ

Proxyの種類へ

Command パターン

目的	Commandパターンは、実行可能なアクション(コマンド)をオブジェクトとして扱い、 コマンドの詳細をカプセル化するパターン
メリット	要求の受付と要求に対応する処理を切り離して実装できる。 コマンドの追加や削除に対して柔軟になる。 クラスの再利用性を向上させる 要求と実際の実行を別のタイミングで実施することができる
デメリット	Command パターンを記述すると、関数を記述するよりコードが多くなる * 使用するにはそれなりの理由がなければならない。
クラス図

利用シーン、各役割の説明へ

Interpreter パターン

目的	定義された種類の問題を素早く解くために、ドメイン固有言語を実装 ドメイン固有言語を解析し, その結果得られた手順 (命令) に基づき処理を実行していく 一般的な方法としては、各シンボル(終端記号-TerminalExpressionと非終端記号-NonterminalExpression)ごとにクラスを持つ ドメイン固有言語 = 特定のタスク向けに設計されたコンピュータ言語 Interpreter = 「通訳者」「解釈者」。言語の文法表現を通訳。
メリット	特化言語は汎用の言語よりも数倍から数百倍高速に問題を解ける場合が多い
利用例	データベースに特化した問い合わせ言語（SQLなど） 通信プロトコルを記述するために良く用いられる特化したコンピュータ言語 特化言語を導入した汎用のコンピュータ言語
クラス図

各役割の説明へ