должна быть возможность добавления новых функциональных возможностей в классы некоторой иерархии, без изменения интерфейса базового класса. Виды возможного поведения должны быть постоянными, в то время как операции для разных классов должны выполняться по-разному.

на Шаблон Visitor позволяет сконцентрировать все операции в одном классе. Там может быть много Concrete Element классы (из диаграммы), но для каждого из них будет реализовано visit() метод Concrete Visitor класс, который определит свой собственный алгоритм.

определение и реализация метода для каждого подкласса Element класс:

public interface Visitor {
    void visit(Element element);
}

public class ConcreteVisitor implements Visitor {
    public void visit(Element element) {
        // implementation
    }
}

на Шаблон Visitor легко расширяется для новых операций путем реализации этого интерфейса новым классом с его реализацией метода.

следующая структура инкапсулирует Element класс:

public lass ObjectStructure {
    private Element element;
    // some methods
}

этой ObjectStructure класс может агрегировать один или несколько экземпляров Element. Презентации Visitor действует на:

public interface Element {
    void accept(Visitor visitor);
}

и реализации accept() метод в конкретной сущности:

public class ConcreteElement implements Element {
    public void accept(Visitor visitor) {
        visitor.visit();
    }
}

использование Шаблон Visitor позволяет сохранить Element иерархия из огромной логической функциональности или сложной конфигурации.

желательно добавить функциональность ко всем классам иерархии при определении нового Visitor подклассы. Но может возникнуть проблема:--5--> должны быть переопределенным для каждого типа иерархии. Чтобы избежать этого лучше определить AbstractVisitor класс и все оставляют его всем visit() способ тела пустые.

вывод: использование этого шаблона хорошо, когда иерархия классов типа Element остается неизменным. Если добавляются новые классы, это обычно приводит к значительным изменениям в классах Visitor тип.

мой ответ очень похож на Михаэля фон Венкштерна, с улучшениями, которые у нас есть по имени accept метод (больше похож на стандартный шаблон) и что мы обрабатываем неизвестные конкретные классы-нет никакой гарантии, что в какой-то момент конкретная реализация, которую мы не видели раньше, не появится на пути к классам. Мой посетитель также позволяет возвращаемое значение.

Я также использовал более подробное имя visit методы, включая тип в имя метода, но это не необходимо, вы можете назвать их все visit.

// these classes cannot be modified and do not have source available

class Legacy {
}

class Legacy1 extends Legacy {
}
class Legacy2 extends Legacy {
}

// this is the implementation of your visitor    

abstract class LegacyVisitor<T> {
    abstract T visitLegacy1(Legacy1 l);
    abstract T visitLegacy2(Legacy2 l);

    T accept(Legacy l) {
        if (l instanceof Legacy1) {
            return visitLegacy1((Legacy1)l);
        } else if (l instanceof Legacy2) {
            return visitLegacy2((Legacy2)l);
        } else {
            throw new RuntimeException("Unknown concrete Legacy subclass:" + l.getClass());
        }
    }
}
public class Test {
    public static void main(String[] args) {
        String s = new LegacyVisitor<String>() {

            @Override
            String visitLegacy1(Legacy1 l) {
                return "It's a 1";
            }

            @Override
            String visitLegacy2(Legacy2 l) {
                return "It's a 2";
            }
        }.accept(new Legacy1());

        System.out.println(s);
    }
}

сначала я должен был сделать несколько предположений о устаревшем коде, так как вы не предоставили много подробностей об этом. Допустим, мне нужно добавить новый метод Legacy без переопределения все. Вот как я это сделаю:--7-->

public interface LegacyInterface {
    void A();
}

public final class LegacyClass implements LegacyInterface {
    @Override
    public void A() {
        System.out.println("Hello from A");
    }
}

сначала продлевает "контракт"

public interface MyInterface extends LegacyInterface {
    void B();
}

и реализовать его в "оформлен" путем

public final class MyClass implements MyInterface {
    private final LegacyInterface origin;

    public MyClass(LegacyInterface origin) {
        this.origin = origin;
    }

    @Override
    public void A() {
        origin.A();
    }

    @Override
    public void B() {
        System.out.println("Hello from B");
    }
}

ключевым моментом является MyInterface extends LegacyInterface: это гарантия реализации выиграют от как службы из устаревшего кода, так и ваши личные добавления.

использование

MyInterface b = new MyClass(new LegacyClass());

Я думаю, что лучший подход-это Option 1: расширьте еще одну иерархию наследования поверх класса третьей стороны и реализуйте шаблон посетителя с двойной отправкой.

проблема заключается в количестве дополнительных классов, которые вам нужны, но это можно решить с помощью динамического декоратора обертки. Декоратор обертки-это способ добавить реализацию интерфейса, методы и свойства к уже существующим obejcts: как реализовать декоратор обертки в Ява?

таким образом, вам нужен ваш Visitor интерфейс и поставить там visit(L legacy) методы:

public interface Visitor<L> {
    public void visit(L legacy);
}

в AcceptInterceptor вы можете поместить код для метода accept

public class AcceptInterceptor {

    @RuntimeType
    public static Object intercept(@This WrappedAcceptor proxy, @Argument(0) Visitor visitor) throws Exception {
        visitor.visit(proxy);
    }
}

The WrappedAcceptor интерфейс определяет метод, чтобы принять посетителя и установить и получить завернутый объект

interface WrappedAcceptor<V> {
   Object getWrapped();
   void setWrapped(Object wrapped);
   void accept(V visitor); 
}

и, наконец, код утилиты для создания обертки вокруг любого obect:

Class<? extends Object> proxyType = new ByteBuddy()
 .subclass(legacyObject.getClass(), ConstructorStrategy.Default.IMITATE_SUPER_TYPE_PUBLIC)
 .method(anyOf(WrappedAcceptor.class.getMethods())).intercept(MethodDelegation.to(AcceptInterceptor.class))
 .defineField("wrapped", Object.class, Visibility.PRIVATE)
 .implement(WrappedAcceptor.class).intercept(FieldAccessor.ofBeanProperty())
 .make()
 .load(getClass().getClassLoader(), ClassLoadingStrategy.Default.WRAPPER)
 .getLoaded();
WrappedAcceptor wrapper = (WrappedAcceptor) proxyType.newInstance();
wrapper.setWrapped(legacyObject);

если ваша библиотека не имеет accept методы, которые вам нужно сделать с instanceof. (Обычно вы дважды выполняете одинарную диспетчеризацию на Java для эмуляции двойной диспетчеризации; но здесь мы используем instanceof для эмуляции двойной диспетчеризации).

вот пример:

interface Library {
  public void get1();
  public void get2();
}

public class Library1 implements Library {
  public void get1() { ... }
  public void get2() { ... }
}

public class Library2 implements Library {
  public void get1() { ... }
  public void get2() { ... }
}

interface Visitor {
   default void visit(Library1 l1) {}
   default void visit(Library2 l2) {}

   default void visit(Library l) {
      // add here instanceof for double dispatching
      if (l instanceof Library1) {
          visit((Library1) l);
      }
      else if (l instanceof Library2) {
          visit((Library2) l);
      }
   }
}

// add extra print methods to the library
public class PrinterVisitor implements Visitor {
   void visit(Library1 l1) {
       System.out.println("I am library1");
   } 
   void visit(Library2 l2) {
       System.out.println("I am library2");
   }        
}

и теперь в любом методе можно написать:

Library l = new Library1();
PrinterVisitor pv = new PrinterVisitor();
pv.visit(l);

и он напечатает вам "я-библиотека";