ねらい

モチベーション

例) プログラムの解析・コード解析等
AST: Abstract Sytax Tree(抽象構文木)は、さまざまなNode派生クラスのオブジェクトからなる
- AssinmentNode
  代入演算
- VariableRefNode
  変数読み出し
ASTに対してさまざまな操作を行いたい
- 型チェック
- オブジェクトコード生成
- pretty print
Visitorパターンを知らないと、こういった操作を、各Node派生に実装したくなる
- AssignmentNode::TypeCheck()
- VariableRefNode::TypeCheck()
そうすると、下記のようなデメリットが生じる
- 同じ目的の操作が各Node派生に散らばり、理解しづらくなる
- 操作を追加するたびに、Nodeに変更を加えなければならない
  - Nodeクラス利用側が影響を受ける
  - Nodeの全派生クラスが影響を受ける
    - 再コンパイルが必要
同じ目的の操作を1つのクラスに切り出したい … Visitorクラス

オブジェクト構造がさまざまなクラス(ConcreteElement)から構成されている
- クラスごとに異なる操作を行いたい
目的が同じ操作を、各ConcreteElementに散らかしたくない
- AssignmentNode::TypeCheck()
- VariableRefNode::TypeCheck()
ConcreteElementクラスが追加されることはあまりない
- しょっちゅう追加されるならVisitorパターンは不向き

Visitor
- 各ConcreteElementに対応するVisitメソッドの定義
  - 名前を分ける
  - 同じ名前でオーバーロード
ConcreteVisitor
- 目的が同じ1つの操作ごとに派生をつくる
  - 【補】型チェック用Visitor派生の例
    - TypeCheckVisitor::VisitAssignmentNode(AssignmentNode node)
    - TypeCheckVisitor::VisitVariableRefNode(VariableRefNode node)
- オブジェクト構造を走査する際、状態を蓄積できる
  - 【補】例) 変数の被参照箇所を数えるなど
Element
- Accept(Visitor visitor)メソッドの定義
ConcreteElement
- Acceptメソッドの実装
  - VisitorのどのVisitメソッドで操作されればよいかを知っている
  - 【補】オーバーロード実装なら知らなくてもいい
オブジェクト構造
- elementオブジェクトをまとめた構造
  - Composite
  - 汎用コレクション
    - Array
    - List
    - etc.

クライアントコードはconcreteVisitorを生成
オブジェクト構造を走査するさい、element->Accept(concreteVisitor)する
Element派生は、visitorを受け取ったら、しかるべきVisitメソッドを呼び出す
- visitor->VisitXxx(this)
2.でelementによるシングルディスパッチ、3.でvisitorによるシングルディスパッチにより処理が決定される
- 動的ポリモーフィズム
- 正味、elementとvisitorのダブルディスパッチになる

新しい操作の追加が楽
- ConcreteVisitorクラスを追加するだけ
- Element側に変更は生じない
ConcreteVisitorに、目的が同じ関連する操作がひとまとめになる
- 関連しないものは別のConcreteVisitorにまとまる
ConcreteElementの追加は大変になる
- Visitorと全派生に、対応するVisitメソッドを追加しなければならない
- ConcreteElementがしょっちゅう追加されるならVisitorパターンは不向き
Visitする対象は同じ継承ツリーにいる必要はない
- 構造を参照
状態を蓄積できる
- 【補】コードの静的解析において、変数の被参照回数を数えるなど
カプセル化を壊してしまうことがある
- ConcreteElementAは、全ConcreteVisitorのVisitA(ConcreteElementA element)メソッドで用を満たせるインターフェースを持たねばならない
- ConcreteElementAはpublicなgetterまみれになりカプセル化が台無しになることも
  - 【所感】friendにしてはどうか？