訪問者の安定性とインスタンスの柔軟性

設定ファイルを生成するGUIアプリケーションに取り組んでいます。構成モデルのクラス階層があり、その階層のオブジェクトツリーをいくつかの異なるコンテキストで使用しています。現在、ビジターパターンを使用して、コンテキスト固有のコードでモデルクラスを汚染しないようにしています。

interface IConfigurationElement {
    void acceptVisitor(IConfigurationElementVisitor visitor);
}

以前のバージョンinstanceofでは、ビジターの代わりに一連の条件を使用していました。2つのアプローチを比較すると、次のトレードオフが見られます。

ビジター

• 新しいを追加する方が簡単で安全IConfigurationElementです。新しい宣言をに追加するだけIConfigurationElementVisitorで、コンパイラはすべてのビジター実装に対してエラーを生成します。ではinstanceofチェーンあなたは、新しい構成要素を拡張する必要があるすべての場所を覚えておく必要があります。instanceof複数の場所でロジックを複製するため、基本的にDRY原則に違反します。
• 訪問者パターンは一連の条件よりも効率的ですinstanceof

instanceof

• の大きな利点instanceofは、その柔軟性です。たとえば、場合instanceof によっては同様にIConfigurationElement処理する必要がある実装のさまざまなサブセットに対して特別なソリューションを定義できます。対照的に、Visitorでは毎回、各実装クラスのメソッドを実装する必要があります。

この種の問題に対する一般的な解決策はありますか？どういうわけかビジターを適応させることができるので、いくつかのケースに共通のソリューションを提供できますか？

instanceOfでビジターを使用できます

インターフェース：

interface Visitable {
  void accept(Object visitor);
}
interface AVisitor {
  void visitA(A a);
}
interface BVisitor {
  void visitB(B b);
}
interface CVisitor {
  void visitB(C c);
}

Visitables：

class C implements Visitable {
  public void accept(Object visitor) {
    if (visitor instanceof CVisitor) {
      ((BVisitor)vistor).visitC(this);
    }
  }
}

class B implements Visitable {
  public void accept(Object visitor) {
    if (visitor instanceof BVisitor) {
      ((BVisitor)vistor).visitB(this);
    }
  }
}

class A extends B implements Visitable {
  public void accept(Object visitor) {
    super.accept(visitor);
    if (visitor instanceof AVisitor) {
      ((AVisitor)vistor).visitA(this);
    }
  }
}

訪問者：

class PrintBs implements BVisitor {
  public void visitB(B b) {
    system.out.println(b);
  }
}

class PrintAs implements AVisitor {
  public void visitA(A a) {
    system.out.println(a);
  }
}

class PrintCs implements CVisitor {
  public void visitC(C c) {
    system.out.println(c);
  }
}
class PrintAsAndCs implements CVisitor, AVisitor{
  public void visitA(A a) {
    system.out.println(a);
  }
  public void visitC(C c) {
    system.out.println(c);
  }
}

各クラスは関連するインターフェースのみを認識しているため、新しいビジターまたはビジタブルを追加するには、そのカテゴリ（ビジター/ビジター）のすべてを変更する必要があります（ビジターの場合は何も変更する必要はありません。ビジブルの場合は新しいビジターインターフェースを作成する必要がありますが、ここでも既存のオブジェクトの変更）。

このように、instanceofテストのチェーンはなく、サブセットのビジターはこのサブセット外の型について知る必要さえありません。

質問は、AがBを拡張する（そしてBもVisitableである）状況で何をするかです。その場合、super.accept（visitor）をacceptに追加するだけです（したがって、instanceof-sの短いチェーンになりますが、onlu as階層が深い限り、そしてそれが問題になるほど深くないはずですが、手動で全体を記述する必要はありません）。

ええ、そうです。多くの構成要素に役割を割り当てることにより、それらに共通性を持たせます。あなたはinstanceofに終わるかもしれませんが、DRYの原則に違反する方法ではなく、Javaの静的型付けを回避する方法としてです。

class ConfigurationElementA implements IConfigurationElement, ICommittable {
}

class ConfigurationElementB implements IConfigurationElement, IVerifiable {
}

class Visitor {
    void accept(IConfigurationElement element) {
        if (element instanceof ICommittable) {
            // ...
        }

        // Note: not a chain of instanceofs.

        if (element instanceof IVerifiable) {
            // ...
        }
    }
}

言い換えると、訪問者に構成要素を総称的に受け入れさせ、ロールを介して実装のグループに作用させることができます。それに応じて構成要素をモデル化することで、必要に応じて具体的にすることができます。

ここで、Martin FowlerのRoleInterfaceパターンを認識できます。

私はいくつかの潜在的な解決策を考えることができます：

1. Visitor実装でプライベートメソッドを作成し、実装で複数のvisitメソッドを使用してVisitorそのプライベートメソッドを呼び出します。

2. 上記が多くの場所で繰り返される場合、Visitorをvisit実装し、実装のサブセットを共通のprotected abstractメソッドにリダイレクトする抽象クラスの作成を検討できます。

3. 複数のVisitorインターフェースを作成します。

   interface AOrB extends IConfigurationElementVisitor {
       <Result> Result accept(AOrBVisitor<Result> visitor);
   
       interface AOrBVisitor<Result> {
           Result visit(A a);
           Result visit(B b);
       }
   }
   
   interface ThisCouldBeOfTypeB extends IConfigurationElementVisitor {
       <Result> Result accept(ThisCouldBeOfTypeBVisitor<Result> visitor);
   
       interface ThisCouldBeOfTypeBVisitor<Result> {
           Result visit(B b);
           Result visit(ThisCouldBeOfTypeB visitable);
       }
   }
   
   class A implements AOrB, ThisCouldBeOfTypeB {...}
   
   class B implements AOrB, ThisCouldBeOfTypeB {...}
   
   class C implements ThisCouldBeOfTypeB {...}

3はあなたが探しているものだと思います。100％静的なポリモーフィズムであり、型が処理されない場合はコンパイラ警告が生成されます。しかし、私が考えることができる唯一の欠点Visitable*は、さまざまなVisitable*インターフェースが多数ある場合、実装の維持が複雑になる可能性があることです。