- 数え上げ
- 変換
- Wrapperとも
- クラスによるAdaptorパターン(継承)
- 適合させられる側を継承する
- 継承した子クラスで、親クラスのメソッドを呼び出す
- 継承した子クラスは、規定されたintefaceを実装している
- インスタンスによるAdaptorパターン(委譲)
- 適合させられる側を、クラスフィールドに持つ。コンストラクタで持つ
- 初期化する際に、コンストラクタからフィールドに設定する
- フィールドからメソッドを持つ
- スーパークラスで処理の枠組みを定め、サブクラスでその具体的内容を決める
- comment
- 統一的にできるのがメリットかもしれない
- 例えば、エラーの返し方などを統一的にしたいときにテンプレートメソッドパターンを用いると、プログラム全体で統一的な返し方ができる
- 以下の特徴を、インスタンス生成の時に応用したもの
- Template methodのスーパークラスで骨組み、サブクラスで処理の具体化
- インスタンスがだた一つであることを保証する
- Threadと絡めて理解できるようにしたい
- インスタンス化する代わりに、コピーしてインスタンスを作成する
- 種類が多すぎてクラスにまとめられない
- クラスからのインスタンス生成が難しい
- フレームワークと生成するインスタンスを分ける
- Director
- Builderを利用してインスタンスを生成
- Builder
- インスタンスを作成するためのインターフェイスを定める
- ConcreteBuilder
- Builderを実装している
- 具体には注目せずに、インターフェイスにだけ着目してプログラムを作る
- 機能のクラスと実装のクラスを橋渡しする
- 戦略・アルゴリズムを置き換える
- 容器と中身を同一視して、再帰的な構造を作る
- 容器と中身をそのひとつ上のレイヤーで捉える
- 中心となるオブジェクトに飾りをつけていく
- データ構造と処理を分離
- データ構造を中を移動する訪問書を表す区rすを準備して、そのクラスに処理を任せる
- 新しい機能を追加したい時には、その訪問者を新しく作るようにする
- 複数のオブジェクトを繋いでおき、そのオブジェクトの鎖を順次渡り歩いて、目的のオブジェクトを決定すること
- その処理を決定するオブジェクトを一つに決められれない場合に用いる
- 要求する側のと処理する側の結びつきを弱めることができる
- これべるのインターフェースを提供する。システムの内側に対しては、役割や依存関係を考えて、正しい順番でクラスを利用する
- mediatorとcolleague
- 全体調整薬と、その調整薬の判断nに合わせて動く人
- 多数のオブジェクトの調整を行わなければならない時こそ、Mediatorパターンの出番
- ここのオブジェクトが互いに通信しなうのではなく、頼りになる相談役をおき、その相談役とだけ通信する
- 全体のコントロールロジックは、相談役の中にだけ記述する
- DDDとかの場合にはどうするのか？これはドメイン知識になるのではないか
- 状態の変化を監視する
- インスタンスの状態を表す役割を導入して、カプセル化の破壊に陥ることなく保存と復元を行うこと
- カプセル化の破壊
- インスタンスを復元するためいは、インスタンスの内部の情報に自由にアクセスできる必要がある。しかし、不用意にアクセスを許すことによってクラスの内部構造に依存したコードがプログラムのあちこちに散らばり、クラスの修正がしにくくなってしまうこと
- 状態をクラスとして表現する
- オブジェクトのメモリ使用量を減らす
- インスタンスをできるだけ共有して、無駄にインスタンス化しない
- 必要になってから作る。代理人に対応できる範囲の仕事を任せる
- 命令それ自体をクラスとする
- 文法規則をクラスで表現する
- プログラムが解決しようとする問題を、ミニ言語で表す。問題が変化した時には、ミニ言語の方を書き換える
- 実行するJava言語の方は、変更が不要になる