visitor

Visitor

アルゴリズムを操作対象のオブジェクトから分離できる動作設計パターン

複雑なオブジェクト構造のすべての要素（オブジェクトツリーなど）に対して操作を実行する必要がある場合

メリット

• オープン/クローズド原則。クラスを変更せずに、異なるクラスのオブジェクトを操作できる新しい動作を導入できます。
• 単一責任の原則。同じ動作の複数のバージョンを同じクラスに移動できます。
• さまざまなオブジェクトを操作しているときに、いくつかの有用な情報を蓄積できます。オブジェクトツリーなどの複雑なオブジェクト構造をトラバースし、この構造の各オブジェクトにビジターを適用する場合に便利。

デメリット

• クラスが要素階層に追加または要素階層から削除されるたびに、すべてのVisitorを更新する必要があります。
• 作業することになっている要素のプライベートフィールドとメソッドへの必要なアクセスを欠いている可能性があります。

他パターンとの関係性

• Commandより強力
• Compositeツリー全体に操作を実行できる
• Iteratorと一緒に使用して、複雑なデータ構造をトラバースし、その要素に対して何らかの操作を実行できる

例題

• 実際に構造体を変更せずに、構造体に動作を追加できる

• 次のlibをメンテナンスする場合

  • 四角
  • サークル
  • 三角形

• 共通の形状インターフェースを実装している

• チームがgetAreaをshape構造体に追加するように要求

• これを解決するには3つ

1. getAreaメソッドをshapeインターフェイスに直接追加してから、各shape構造体に実装する
   • コストが高い
   • 誰かが別の動作を要求するたびに貴重なコードを壊す可能性が高い
2. 機能を要求するチームが自分で動作を実装できる
   • プライベートコードに依存する可能性があるため、これが常に可能であるとは限らない
3. Visitorパターン
   • visitorインターフェイスの具体的な実装を定義し、その具体的な実装に面積計算ロジックを記述するだけ