Builderによるcompositeの隠蔽

14
Builder ににに Composite ににに パパパパパパパパパパパパパパパパPDF: P.130 )

Transcript of Builderによるcompositeの隠蔽

Page 1: Builderによるcompositeの隠蔽

BuilderによるCompositeの隠蔽パターン指向リファクタリング入門( PDF: P.130 ~ )

Page 2: Builderによるcompositeの隠蔽

2

Builderによる Compositeの隠蔽 (P.130)

▪ Composite の構造処理が何度も出現したり、

 複雑であったり、あるいはエラーを起こしやすいものになっている。

TagNode多すぎィ!

Page 3: Builderによるcompositeの隠蔽

3

Builderによる Compositeの隠蔽 (P.130)

▪ 詳細部分を Builderに任せることで、構築を単純化する。

TagBuilder1回呼び出すだけ

TagNodeを TagBuilderで隠蔽する

Page 4: Builderによるcompositeの隠蔽

4

動機 (P.131)

1. 複数オブジェクトを生成するクライアントコードを単純化するため

▪ オブジェクトの生成に関する難解で面倒な部分を Builder が実装していれば,クライアントは,生成がどのように行われるかを知らなくても,Builder に生成を指示することができる。

▪ 例:親ノードに子ノードを追加するときにクライアントで行う操作新しいノードをインスタンス化新しいノードを初期化新しいノードを正しい親ノードに適切に追加

操作不要根のノードが分かれば操作不要

Page 5: Builderによるcompositeの隠蔽

5

動機 (P.131)

2. クライアントコードと Composite コードとを切り離すため

▪ 前回の「 Composite による暗黙的なツリー構造の置き換え」を行ったときに発生する問題

▪ クライアントコードと Composite コードが緊密に結合していると, Composite の実装を変更するのが困難になる。

Page 6: Builderによるcompositeの隠蔽

6

▪ 例:クライアントコードと DOM のインタフェース/クラスを切り離す

Clientと直接関連をもつ

DOMBuilderでワンクッション挟む→環境構築 (更新 )が容易になる(新しい Ver.の DOMへの入れ替え等 )

Page 7: Builderによるcompositeの隠蔽

7

Builderパターンの目的 (P.131)

▪ 複数オブジェクトについて、その作成過程を表現形式に依存しないものにすることにより、同じ作成過程で異なる表現形式のオブジェクトを生成できるようにする。 ー  GoF [DP 、 105 ページより引用 ]

▪ 作成過程を表現形式に依存しないものにする▪ → 子ノードが増えても、クライアントに子ノードのことを書かない

▪ 同じ作成過程で異なる表現形式▪ →Composite を隠蔽しているだけなので作成過程は変わっていない

▪ →Builder で隠蔽しているので表現形式が異なる

Page 8: Builderによるcompositeの隠蔽

8

Builderの補足 (P.131)

▪ Builder が提供するサービス▪ 異なる表現形式のオブジェクトを生成できる

▪ 構築を単純化する▪ クライアントコードと複合オブジェクトを切り離す

▪ 概要はわかりやすく詳細がわかりづらい Builder▪ Builder のインタフェースは明確に意図が伝わるものでなければならな

▪ が、構築を単純化するために詳細な部分は隠蔽しているため見えづらい▪ 詳細を知るには Builder の実装/テストコード/ドキュメントを要

チェック

Page 9: Builderによるcompositeの隠蔽

9

利点・欠点 (P.133)

Good Point

▪ Composite を構築するクライアントコードを単純化できる。

▪ Composite の生成にまつわる繰り返しやエラーを軽減できる。

▪ クライアントと Composite の間の結合度が低くなる

▪ カプセル化された Composite や複合オブジェクトを異なった形式で表現できる

Bad Point

▪ インタフェースの意図が伝わりにくくなる可能性がある

Page 10: Builderによるcompositeの隠蔽

10

手順 (P.133-134)

基本の流れ。適宜カスタマイズしてね。

1. 新しい Builder クラスを作る

2. Builder が子ノードを構築できるようにする

3. ノードの属性や値を Builder が設定できるようにする

4. 作成した Builder を Client がどの程度簡単に使えるのか見直し、手直す。

5. 新しい Builder を Composite 構築コードをリファクタリングする。

Page 11: Builderによるcompositeの隠蔽

11

例 (P.134)

本読みながらでいいかな?

Page 12: Builderによるcompositeの隠蔽

12

新しく作成した Builderの性能改善

▪ (詳しい説明の必要性を感じなかった)

▪ Builder に対して性能改善を施した。

▪ Composite を隠蔽したように,性能改善ロジックもカプセル化したので, Builder のユーザから見ると何も変わっていないのに性能が良くなった。

StringBufferが原因ならBuilderじゃなくてもユーザ影響少なそう。

Page 13: Builderによるcompositeの隠蔽

13

変化形:スキーマベースの Builder

▪ XML スキーマを TreeSchema に変換するとかどうとか

▪ たぶん XML にしか使えない。

難しいのでみんなで読みましょう

Page 14: Builderによるcompositeの隠蔽

14