COMPOSITE †
要約 †
- p315 1
部分と全体の階層構造でオブジェクトを構成してください。
COMPOSITEはクライアントにここのオブジェクトと組み合わさったオブジェクトを均一に扱わせることができます。
- p315 2
複合ドメインをモデル化しているとき、部品を組み合わせた、それ自身が部品の一部であるような重要なオブジェクトに遭遇する。
- p315 3
関連性のあるネストしたコンテナがモデルに反映されないとき、共通の振る舞いをお互いの階層でもつ必要がある。
概念的な違いはないのかもしれないが、クライアントは異なったインターフェースを通し、異なった階層レベルに対して対処しなければならない。
- p315 4
設計パターンをドメインに適用するときは、最初の関心事はパターンがドメインのコンセプトにマッチするかです。
関連のあるオブジェクトが再帰的に動作することが便利かもしれませんが、部分と全体という階層構造をとるのがよいのでしょうか？
それが正しいのならば、COMPOSITEはモデルを明確にするでしょう。
- p316 1:Therefore:
COMPOSITEのすべてのメンバーを含む抽象型を定義する。
メソッドの戻り値は、コンテンツの集められた情報を返すためのコンテナで実装される。
"Leaf"というノードは、それ自身が持つ値を元にメソッドを実装する。
クライアントは、コンテナとLeavesを区別する必要はない。
- 316 2
これは構造レベルでは比較的明白なパターンですが、設計者でさえそれ自体を操作レベルのパターンとして具体化しようとはしない。
COMPOSITEはすべての構造レベルで同じ振る舞いを提供する。
その正確な対象性はパターンの力の鍵となります。
- p316 3 Example:Shipment Routes Made of Routes
(ここは図の説明)
完全な輸送船のルートは複雑だ。
コンテナは鉄道の終端までトラックで運ばれ、その後港に運ばれ、そして船で別の港に運ばれる。可能ならほかの船に移され、最後には一方の終端まで運ばれる。
- p317 1
アプリケーションの開発チームは、長いLegを組み立ててルートを作るようなオブジェクトモデルを独断で作った。
- p317 2
このモデルを使うと、開発者は予約要求に応じたルートオブジェクトを作ることができる。
- p317 3
開発者はLegsを区別することなくルートを考える。
- p317 4
一方ドメインエキスパートは、5つの論理的な部分に分けた形でルートを理解します。
- p317 5
サブルートが異なった人により、異なった時間で計画されるかもしれなく、それはほかのものと区別されなければなりません。
さらに、"door legs"は他のものとは異なっており、地元のトラックが雇われることもあれば、顧客が運ぶ事もある。
- p318 1
これらすべてが区別された形で反映されたオブジェクトモデルは複雑になる。
- p318 2
構造的にモデルは悪くはない。
しかし、手続きに均一性がなくなり、コードや振る舞いの記述が複雑になる。
- p318 3
COMPOSITEを見てみると、とてもよいように見える。
すべてのレベルのルートは、コンテナの動きとなる。
- p318 4
静的なクラス図では"door legs"とほかのセグメントが堂関係するかについてあまり示されていません。
しかし、モデルは静的なクラスズ以上です。
ほかのダイアグラム(オブジェクト図?)を通して、組み立て情報を伝えるつもりである。
- p320 1
これによりいろいろなことができるという例。
最後のルートをはずしたり、別の最後をくっつけたり・・・。
- p320 2
もちろん、私たちはそのようなオプションはまだ必要にはなりません。
その前に、ルートセグメントや"door legs"が必要で、COMPSITEなしがよいでしょう。
設計パターンはそれが必要になったときに適用すべきです。
担当者のつぶやき †
うーん、この例ではCOMPOSITEはやりすぎということなの？
私が間違ってる？
