Stabilità dei visitatori rispetto alla flessibilità dell'istanza

Potresti usare visitor con instanceOf

interfacce:

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

visitabili:

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);
    }
  }
}

Visitatori:

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);
  }
}

ogni classe conosce solo le sue interfacce correlate, quindi aggiungere nuovi visitatori o visitabili richiede di cambiare tutto in quella categoria (visitatore / visitabile) (per visitatore, non richiede modifiche, per visitabile richiede la creazione di una nuova interfaccia visitatore, ma di nuovo, nessuna modifica di oggetti esistenti).

In questo modo, non esiste una catena di istanze di test e il visitatore di sottoinsieme non ha bisogno di sapere nemmeno di tipi al di fuori di questo sottoinsieme.

La domanda è cosa fare con la situazione in cui A estende B (e B è Visitabile anche), in tal caso, puoi semplicemente aggiungere super.accept (visitatore) in accept (quindi sarebbe una catena corta di instanceof-s, ma onlu finché la gerarchia è profonda, e non dovrebbe essere troppo profonda per importare, e non è necessario scriverla interamente manualmente).

Beh, sì, potresti. Cattura le caratteristiche comuni dei molti elementi di configurazione assegnando loro dei ruoli. Si può finire con instanceof, ma non in un modo che viola il principio di DRY, ma piuttosto come un modo per aggirare la tipizzazione statica di 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) {
            // ...
        }
    }
}

In altre parole, si consente al visitatore di accettare genericamente elementi di configurazione e di agire su gruppi di implementazioni tramite ruoli. Tieni presente che puoi andare specifico di cui hai bisogno modellando i tuoi elementi di configurazione di conseguenza.

Puoi riconoscere qui il pattern RoleInterface di Martin Fowler.

Posso pensare ad alcune soluzioni potenziali:

1. crea un metodo privato nell'implementazione Visitor e disponi di più metodi visit nella chiamata di implementazione Visitor del metodo privato.

2. se quanto sopra viene ripetuto in molti punti, puoi considerare la creazione di una classe astratta che implementa Visitor e reindirizza un sottoinsieme di implementazioni visit a un comune metodo protected abstract .

3. crea più interfacce 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 {...}
   

Penso che 3 sia quello che stai cercando. è un polimorfismo statico al 100% e genera avvisi del compilatore se un tipo non viene gestito. Ma l'unico svantaggio che posso pensare a 3 è che il mantenimento delle implementazioni Visitable* potrebbe diventare complesso se ci sono molte diverse interfacce Visitable* .