TL;DR: допустим, у вас есть N классов с M операциями в каждом. Вам нужен шаблон посетителя, только если M может расти, а N уже велико. В противном случае используйте полиморфизм.

Может быть, я толкну открытую дверь, потому что вы уже подумали об этом, но вот несколько мыслей.

Шаблон посетителя

В общем случае вы будете использовать шаблон посетителя только в том случае, если вы хотите добавить новые операции без рефакторинга всех классов. Это когда M может расти, а N уже большое.

Для каждой новой операции вы создаете нового посетителя. Этот посетитель принимает N классов и обрабатывает операцию для каждого из них:

public class NewOperationVisitor implements Visitor
{
   public void visit(TypeA typeA) {
        // apply my new operation to typeA
   }
   public void visit(TypeB typeB) {
        // apply my new operation to typeB
   }
   ...
}

Таким образом, вам не нужно добавлять новую операцию ко всем N классам, но вам придется проводить рефакторинг каждого посетителя, если вы добавляете класс.

Полиморфизм

Теперь, если M стабилен, пожалуйста, избегайте шаблона посетителя: используйте полиморфизм. Каждый класс имеет четко определенный набор методов (примерно по одному на операцию). Если вы добавляете класс, просто определите известные операции для этого класса:

public class TypeX implements Operator 
{
    public void operation1() {
        // pretty simple
    }

    public void operation2() {
        // pretty simple
    }
}

Теперь, вам придется реорганизовать каждый класс, если вы добавите операцию, но добавить класс очень просто.

Этот компромисс объясняется в «Чистом коде» Р. К. Мартина (6. Объекты и структуры данных, антисимметрия данных/объектов):

Процедурный код [здесь: посетитель] затрудняет добавление новых структур данных, потому что все функции должны измениться. Код OO затрудняет добавление новых функций, потому что все классы должны измениться.

Что ты должен делать

1. Как указано в комментарии @radiodef, избегайте отражений и других уловок. Это будет хуже, чем проблема.

2. Четко разделяйте, где вам действительно нужен шаблон посетителя, а где нет. Подсчет классов и операций. Бьюсь об заклад, что в большинстве случаев вам не нужен шаблон посетителя. (Ваши менеджеры, вероятно, правы!). Если вам нужен шаблон посетителя в 10% случаев, возможно, «дополнительные накладные расходы шаблонного кода» будут приемлемыми.

3. Поскольку некоторые из ваших классов TypeX уже являются обертками, возможно, вам нужно лучше обернуть их. Иногда перенос осуществляется снизу вверх: "У моего стороннего класса есть такие методы: я оберну те методы, которые мне нужны, и забуду остальные. И для простоты я оставлю те же имена". Вместо этого вы должны тщательно определить службу, которую должен предоставлять класс TypeX. (Подсказка: загляните в свои if ... instanceof ... тела). Затем снова оберните сторонние библиотеки для предоставления этих услуг.

4. Действительно: избегайте отражения и других уловок.

Что бы я сделал?

Вы попросили в комментарии псевдокод, но я не могу вам его дать, так как имею в виду метод, а не процедуру или алгоритм.

Вот минимальный шаг за шагом, что бы я сделал в такой ситуации.

Изолируйте каждый «большой instanceof переключатель» в методе

Это почти медицинский совет! До:

public void someMethod() {
    ...
    ...
    if(object instanceof TypeA) {
       TypeA typeA = (TypeA) object;
       ...
       ...
    }
    else if(object instanceof TypeB) {
       TypeB typeB = (TypeB) object;
       ...
       ...
    }
    ...
    ...
}

После:

public void someMethod() {
    ...
    ...
    this.whatYouDoInTheSwitch(object, some args);
    ...
    ...
}

И:

private void whatYouDoInTheSwitch(Object object, some args) {
    if(object instanceof TypeA) {
       TypeA typeA = (TypeA) object;
       ...
       ...
    }
    else if(object instanceof TypeB) {
       TypeB typeB = (TypeB) object;
       ...
       ...
    }
}

Любая приличная IDE сделает это бесплатно.

Если вы находитесь в случае, когда вам понадобится шаблон посетителя

Оставьте код таким, но задокументируйте его:

/** Needs fix: use Visitor Pattern, because... (growing set of operations, ...) */
private void whatYouDoInTheSwitch(Object object, some args) {
    ...
}

Если вы хотите использовать полиморфизм

Цель состоит в том, чтобы перейти от:

this.whatYouDoInTheSwitch(object, other args);

To:

object.whatYouDoInTheSwitch(this, other args);

Вам предстоит небольшой рефакторинг:

A. Создайте метод для каждого случая в большом коммутаторе. Все эти методы должны иметь одинаковую сигнатуру, за исключением типа объекта:

private void whatYouDoInTheSwitch(Object object, some args) {
    if(object instanceof TypeA) {
        this.doIt((TypeA) object, some args);
    }
    else if(object instanceof TypeB) {
        this.doIt((TypeB) object, some args);
    }
}

Опять же, любая IDE сделает это бесплатно.

B. Создайте интерфейс следующим методом:

doIt(Caller caller, args);

Где Caller — это тип класса, который вы реорганизуете (тот, который содержит большой переключатель).

C. Сделать так, чтобы каждый TypeX реализовал этот интерфейс, преобразовав каждый doIt(TypeX objX, some args) в метод doIt(Caller, some args) из TypeX. По сути, это простой поиск-замена: заменить this на caller и objX на this. Но это может занять немного больше времени, чем остальные.

Д. Теперь у вас есть:

private void whatYouDoInTheSwitch(Object object, some args) {
    if(object instanceof TypeA) {
        ((TypeA) object).doIt(this, some args);
    }
    else if(object instanceof TypeB) {
        ((TypeB) object).doIt(this, some args);
    }
}

Это строго эквивалентно:

private void whatYouDoInTheSwitch(Object object, some args) {
    if(object instanceof TypeA) {
        object.doIt(this, some args);
    }
    else if(object instanceof TypeB) {
        object.doIt(this, some args);
    }
}

Потому что во время выполнения JVM найдет правильный метод для нужного класса (это полиморфизм!). Таким образом, это также эквивалентно (если объект имеет один из перечисленных типов):

private void whatYouDoInTheSwitch(Object object, some args) {
    object.doIt(this, some args);
}

E. Вставьте метод, и у вас есть в вашем классе Caller:

public void someMethod() {
    ...
    ...
    object.doIt(this, some args);
    ...
    ...
}

На самом деле это только набросок, а частных случаев может быть много. Но он гарантированно будет относительно быстрым и чистым. Это можно сделать только для выбранного метода или для всех методов.

Обязательно проверяйте, если это возможно, код после каждого шага. И не забудьте выбрать правильные имена для методов.

Похоже на полиморфизм. Такой код может быть создан из разнородного набора классов бизнес-объектов, таких как Excel ReportX, Zip, TableY, и таких действий, как "Открыть", "Закрыть", "Сохранить" и т. д.

Как бы то ни было, этот тип программирования вызывает огромную связь между классами и имеет проблемы с полнотой всех случаев, расширяемостью.

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

Этот механизм похож на свинг в Java, где поле редактирования имеет свой список действий (Вырезать, Копировать, Вставить и т. д.), а древовидное представление — перекрывающийся набор действий. В зависимости от фокуса актуальные действия будут установлены в меню действий.

Возможно, подойдет декларативная спецификация: скажем, XML, который "держит" bean-компоненты и их действия.

Если у вас есть какая-то парадигма MVC, учтите следующее: каждое действие может иметь параметры. Используйте PMVC (моя идея), класс Parameters, отличный от класса Model, поскольку эта информация имеет другой жизненный цикл и является постоянной.

Дорога сюда может быть:

• прототип с двумя бизнес-объектами и двумя действиями.
• рефакторинг с одним полиморфным бизнес-объектом, содержащим все (старый код).
• медленно перемещая один класс за другим к их собственному бизнес-объекту.
• первое удаление из бизнес-объекта полиморфа используется для очистки новой архитектуры.

Я бы воздержался от использования наследования (базовый документ с открытием/сохранением), так как это, вероятно, не соответствует более разнородной реальности и может вызвать параллельные иерархии классов (XDoc с XContainer и XObject).

Как это делается на самом деле, остается вашей работой. Мне также очень хотелось бы узнать, существует ли устоявшаяся парадигма.

Заданный псевдокод Требуется небольшой анализ с созданием некоторого прототипа - доказательство концепции. Однако есть открытие (динамических) возможностей/функций.

public interface Capabilities {
    <T> Optional<T> as(Class<T> type);
}

Добавьте этот интерфейс в каждый класс case, и вы сможете:

void f(Capabilities animal) {
    int distance = 45;
    animal.as(Flying.class).ifPresent(bird -> bird.fly(distance));
}

Инфраструктура будет такой: сначала регистрацию возможностей и обнаружение можно вынести в отдельный класс.

/**
 * Capabilities registration & discovery map, one can delegate to.
 */
public class CapabilityLookup implements Capabilities {

    private final Map<Class<?>, Object> capabilitiesMap = new HashMap<>();

    public final <T> void register(Class<T> type, T instance) {
        capabilitiesMap.put(type, instance);
    }

    @Override
    public <T> Optional<T> as(Class<T> type) {
        Object instance = capabilitiesMap.get(type);
        return instance == null ? Optional.empty()
                                : Optional.of(type.cast(instance));
    }
}

Затем унаследованные классы могут быть дополнены:

/** Extended legacy class. */
public class Ape implements Capabilities {

    private final CapabilityLookup lookup = new CapabilityLookup();

    public Ape() {
        lookup.register(String.class, "oook");
    }

    @Override
    public <T> Optional<T> as(Class<T> type) {
        return lookup.as(type); // Delegate to the lookup map.
    }
}

/** Extended legacy class. */
public class Bird implements Capabilities {

    private final CapabilityLookup lookup = new CapabilityLookup();

    public Bird() {
        lookup.register(Flying.class, new Flying() {
            ...
        });
        lookup.register(Singing.class, new Singing() {
            ...
        });
    }

    @Override
    public <T> Optional<T> as(Class<T> type) {
        return lookup.as(type); // Delegate to the lookup map.
    }
}

Как видите, с Bird исходный код переместился бы в фактический класс интерфейса, здесь в Bird, поскольку экземпляр был создан в конструкторе. Но вместо анонимного класса можно было бы создать класс BirdAsFlying, что-то вроде класса действия на языке Java Swing. Внутренний класс имеет преимущество доступа к Bird.this.

Рефакторинг можно выполнять поэтапно. Добавьте возможности ко всем устаревшим классам instanceof. Последовательность if обычно представляет собой один интерфейс, но также может состоять из двух или одного интерфейса с двумя методами.