GoF本 Discussions of Structural Patterns
構造のパターンの類似性
- 登場人物と、クライアントコードからの利用が類似している
- が、ねらいが全然違う
- 【所感】構造とねらいがひとまとめでデザインパターンということですね
AdapterとBridge
共通点
- 柔軟性を上げる
- 間接層を1枚増やし、処理を委譲する
相違点
Adapter | Bridge | |
---|---|---|
ねらい | 既存の2つのクラスのインタフェース不一致を吸収する 作り直すのは大変なので、一方を他方のインタフェースで包む |
実装の抽象化 クライアントコードと実装とを独立して開発できるようにする |
いつ導入される | 後期 2つのクラスを一様に扱うべきということが、当初予期できなかった |
最初期 あらかじめ、複数の実装を一様に扱うつもりで導入する |
AdapterとFacade
言うほど似てなくないか
- Facadeは、複数のクラスからなるサブシステムに新しいインタフェースを提供する
- Adapterは、インタフェースが合わない2つのクラスがあるとき、一方を他方の既存インタフェースに寄せる
CompositeとDecorator
共通点
- 再帰構造
- DecoratorはCompositeの縮退バージョンと捉えられる
- 子ノードが1つだけ
- DecoratorはCompositeの縮退バージョンと捉えられる
相違点
Composite | Decorator | |
---|---|---|
ねらい | 1と部分と全とを一様に扱うこと | オブジェクトへの責務の動的な追加 クラスの継承で静的に行うと派生クラス数が爆発する |
併用
- CompositeパターンとDecoratorとは相補的で、一緒に使われることが多い
- Compositeパターンにおいて、
Decorator
はLeaf
に相当する - Decoratorパターンにおいて、
Composite
はConcreteComponent
に相当する
- Compositeパターンにおいて、
DecoratorとProxy
共通点
- 間接層
相違点
Decorator | Proxy | |
---|---|---|
ねらい | 責務を動的に追加(・削除)すること、 それを再帰的に行えること |
アクセス制御 |
包むオブジェクトとの関係 | 機能が足りないので補完する | 機能を制限することがある |
構造はいつきまる | 実行時 どの機能が必要かは実行時までわからない 静的にすべてを網羅しようとすると組み合わせが爆発する |
コンパイル時 どのクラスのどの機能にアクセス制御すべきかは静的にわかっている |
英語
- stand-in
- 代理
- Proxyと同義か類義
- 代理