GoF本 Discussions of Structural Patterns

GoFデザインパターン勉強メモ

構造のパターンの類似性

  • 登場人物と、クライアントコードからの利用が類似している
  • が、ねらいが全然違う

    • 【所感】構造ねらいひとまとめでデザインパターンということですね

AdapterとBridge

共通点

  • 柔軟性を上げる
  • 間接層を1枚増やし、処理を委譲する

相違点

Adapter Bridge
ねらい 既存の2つのクラスのインタフェース不一致を吸収する
作り直すのは大変なので、一方を他方のインタフェースで包む
実装の抽象化
クライアントコードと実装とを独立して開発できるようにする
いつ導入される 後期
2つのクラスを一様に扱うべきということが、当初予期できなかった
最初期
あらかじめ、複数の実装を一様に扱うつもりで導入する

AdapterとFacade

言うほど似てなくないか

  • Facadeは、複数のクラスからなるサブシステムに新しいインタフェースを提供する
  • Adapterは、インタフェースが合わない2つのクラスがあるとき、一方を他方の既存インタフェースに寄せる

CompositeとDecorator

共通点

  • 再帰構造

    • DecoratorはCompositeの縮退バージョンと捉えられる

      • 子ノードが1つだけ

相違点

Composite Decorator
ねらい 1と部分と全とを一様に扱うこと オブジェクトへの責務の動的な追加
クラスの継承で静的に行うと派生クラス数が爆発する

併用

  • CompositeパターンとDecoratorとは相補的で、一緒に使われることが多い

    • Compositeパターンにおいて、DecoratorLeafに相当する
    • Decoratorパターンにおいて、CompositeConcreteComponentに相当する

DecoratorとProxy

共通点

  • 間接層

相違点

Decorator Proxy
ねらい 責務を動的に追加(・削除)すること、
それを再帰的に行えること
アクセス制御
包むオブジェクトとの関係 機能が足りないので補完する 機能を制限することがある
構造はいつきまる 実行時
どの機能が必要かは実行時までわからない
静的にすべてを網羅しようとすると組み合わせが爆発する
コンパイル時
どのクラスのどの機能にアクセス制御すべきかは静的にわかっている

英語

  • stand-in

    • 代理

      • Proxyと同義か類義