この投稿では、「訪問者」と呼ばれるデザイン パターンについて説明します。または「訪問者」
このパターンは行動パターンのグループに属します。
問題を考えてみましょう
このパターンは主に、早期バインド言語における単一ディスパッチの制限を回避するために使用されます。
アリス X by NFGPhoto (CC-2.0)
抽象クラス/プロトコル Band を作成し、MurpleDeep のサブクラスを作成し、2 つのメソッドを持つ Visitor クラスを作成しましょう。 1 つは Band の子孫をコンソールに出力するためのもので、2 つ目は MurpleDeep を出力するためのものです。主なことは、メソッドの名前 (シグネチャ) が同じで、引数がクラスによってのみ異なることです。 Band 引数を指定した中間出力メソッドを使用して Visitor のインスタンスを作成し、MurpleDeep の visit メソッドを呼び出します。
以下は Kotlin のコードです。
出力は “これはバンド クラスです“
どうしてそんなことが可能なのでしょうか?!
なぜこれが起こるのかは、ロシア語を含む多くの記事で賢明な言葉で説明されていますが、コンパイラーがコードをどのように認識するかを想像してみることをお勧めします。おそらくすべてがすぐに明らかになるでしょう。
問題の解決
この問題を解決するには多くの解決策があります。次に、訪問者パターンを使用した解決策を検討します。
Visitor 引数を持つ accept メソッドを抽象クラス/プロトコルに追加し、メソッド内でvisitor.visit(this) を呼び出し、次に accept メソッドのオーバーライド/実装を MurpleDeep クラスに追加します。これにより、決定的かつ冷静に DRY に違反し、再度次のように記述します。 Visitor.visit(this).< br />最終コード:
ソース
https://refactoring.guru/ru/デザインパターン/訪問者-ダブルディスパッチ
ソースコード
https://gitlab.com/demensdeum/patterns
