読者です 読者をやめる 読者になる 読者になる

kyosho5’s blog

貧乏で数学があまり得意ではない理系出身のエンジニアのブログ

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

第13章 Visitorパターン

データ構造と処理を分離し、データ構造の中を巡り歩く主体である訪問者をあらわすクラスを用意し、
そのクラスに処理を任せる。

・Visitor役
→データ構造の具体的な要素(ConcreteElement役)ごとに「XXXXを訪問した」というvisit(XXXX)メソッドを宣言する。
実際のコードはConcreteVisitor役の中に書かれる。

・ConcreteVisitor役
→ Visitor役のインタフェース(API)を実装する。
visit(XXXX)という形のメソッドを実装し、個々のConcreteElement役ごとの処理を記述する。
具体的な処理はすべて個々に記述できてしまうので、新しいConcreteVisitor役を追加するのは容易である。
(ConcreteElement役を修正する必要がない)

・Element役
→Visitorの訪問先を表す役。訪問者を受け入れるacceptメソッドを宣言する。引数はVisitor役。

・ConcreteElement役
→Element役のインタフェース(API)を実装する役
新しいElement役を追加するときにVisitorクラスのサブクラスすべてに新たなvisit()メソッドを
追加しなければならないため追加が難しい。

・ObjectStructure役
→Element役の集合を扱う役。
ConcreteVisitor役が個々のElement役を使えるようなメソッドを備えている。


データ構造の中に処理を記述せずに分離させるのがVisitorパターンの狙いである。
FileクラスやDirectoryクラスの部品としての独立性を高めることができる。

OCP(Open-Closed-Principle)
→既存のクラスを修正することなく拡張できるようにせよ。

第14章 Chain of Responsibilityパターン

複数のオブジェクトを鎖のようにつないでおき、順次渡り歩いて要求を処理するオブジェクトを決定する

・Handler役
→要求を処理するインタフェース(API)を定める役
たらいまわし先のオブジェクトを保持しておき、自分で処理できない要求が来たらそのオブジェクトにたらいまわしする。
次のオブジェクトもHandler役である。

・ConcreteHandler役
→要求を処理する具体的な役

・Client役
→最初のConcreteHandler役に要求を出す役

要求を出す人と処理するひとを緩やかに結びつける。特定のクラスなどに処理を担当する条件やその知識を中央集権的に
持たせないような構造になっている。
要求を出す人が処理者たちの役割分担の詳細を知らないことで、部品としての独立性が高まる。

委譲を用いることでたらいまわしを行っていれば、要求を処理するConcreteHandler役のオブジェクトの関係が動的に変化しても
その役そのものを組み替えることができる。

自分で処理するか、できなければ次の人に回してしまうというスタンスによって、仕事の振り分け自体をConcreteHandlerに
負わせないで済む。

要求を処理する役が決まっている、処理速度の優先順位が高い場合などはこのパターンをもちいないという判断も必要。