(1)Iteratorパターン
Iteratorパターンは集約オブジェクトの種類や実装に依存しない、統一的な走査方法を提供したいような場合に利用する
(2)Adaptorパターン
Adapter パターンは利用したいインタフェースを強制的に変えたいような場合に利用する
上はTargetを実装しAdapteeを継承する。下はTargetから継承しAdapteeを集約する。
(3)TemplateMethodパターン
スーパークラスで処理の枠組みを定め、サブクラスでその具体的内容を実装する。
(4)FactoryMethodパターン
インスタンスの生成をサブクラスに行わせる
(5)Singletonパターン
あるクラスのインスタンスが一つしかないことを保証する
(6)Prototypeパターン
プロトタイプからインスタンスを生成する
(7)Builderパターン
「作成過程」を決定する Director と呼ばれるものと「表現形式」を決定する Builder と呼ばれるものを組み合わせることで、オブジェクトの生成をより柔軟にし、そのオブジェクトの「作成過程」をもコントロールすることができるようにする
(8)AbstractFactoryパターン
インスタンスの生成を専門に行うクラスを用意することで、整合性を必要とされる一連のオブジェクト群を間違いなく生成する
(9)Bridgeパターン
機能と実装を分離して、それぞれを独立に拡張することができるようになる
(10)Strategyパターン
戦略(Strategy)の切り替えや追加が簡単に行えるようになる
(11)Compositeパターン
「容器と中身を同一視する」ことで、再帰的な構造の取り扱いを容易にする
(図では分かりずらいがComonentからCompositeへ集約している)
(12)Decoratorパターン
飾り枠と中身を同一視することで、より柔軟な機能拡張方法を提供
(13)Visitorパターン
「処理」を訪問者である Visitor オブジェクトに記述することで、処理の追加を簡単にします。処理対象となる、Acceptor オブジェクトは、Visitor オブジェクトを受け入れる accept(Visitor visitor)メソッドを実装している必要があります
(14)Chain of Responsibilityパターン
「責任」を負ったものが、「鎖」状につながれた状態をイメージさせるパターン
(15)Facadeパターン
既存のクラスを複数組み合わせて使う手順を、「窓口」となるクラスを作ってシンプルに利用できるようにする
(16)Mediatorパターン
複数のオブジェクト間の調整をするために、 各オブジェクトからの問い合わせを受け、 適宜判断を行い指示を出す「仲裁人」の役割を果たすクラスを利用する
(17)Observerパターン
状態の変化を観察することを目的としたもの
(18)Mementoパターン
インスタンスのあるときの状態をスナップショットとして保存しておくことで、 その時のインスタンスの状態を復元することを可能にするもの
(19)Stateパターン
状態の変化に応じて振る舞いが変わるような場合に威力を発揮するパターン
(20)Flyweightパターン
同じインスタンスを共有することで、無駄なインスタンスを生成しないようにして、 プログラム全体を軽くすることを目的としたパターン
(21)Proxyパターン
要求を代理人オブジェクトが受け取って処理するパターン
(22)Commandパターン
要求をCommandオブジェクトにして、それらを複数組み合わせて使えるようにするパターン