Считается ли использование оператора instanceof плохим дизайном?

В одном из моих проектов у меня есть два «объекта передачи данных» RecordType1 и RecordType2, которые наследуются от абстрактного класса RecordType.

Я хочу, чтобы оба объекта RecordType обрабатывались одним и тем же классом RecordProcessor в рамках метода «процесса». Моей первой мыслью было создать общий метод процесса, который делегирует два конкретных метода процесса следующим образом:

public RecordType process(RecordType record){

    if (record instanceof RecordType1)
        return process((RecordType1) record);
    else if (record instanceof RecordType2)
        return process((RecordType2) record);

    throw new IllegalArgumentException(record);
}

public RecordType1 process(RecordType1 record){
    // Specific processing for Record Type 1
}

public RecordType2 process(RecordType2 record){
    // Specific processing for Record Type 2
}

Я читал, что Скотт Мейерс пишет следующее в Effective C ++ :

«Каждый раз, когда вы найдете вы пишете код в форме «если объект типа T1, то сделайте что-нибудь, но если он типа T2, то сделайте что-нибудь еще,« ударьте себя »

. Если он прав, очевидно, я должен дать себе пощечину. Я действительно не понимаю, насколько это плохой дизайн (если, конечно, кто-то подклассирует RecordType и не добавляет RecordType3, не добавляя еще одну строку к общему методу Process, который его обрабатывает, создавая таким образом NPE), и альтернативы, которые я могу придумать Из-за того, что основная тяжесть конкретной логики обработки ложится на сами классы RecordType, что на самом деле не имеет для меня особого смысла, поскольку теоретически может быть много различных типов обработки, которые я хотел бы выполнить с этими записями.

Может ли кто-нибудь объяснить, почему это можно считать плохим дизайном и предоставить какую-то альтернативу, которая по-прежнему возлагает ответственность за обработку этих записей на класс «Processing»?

ОБНОВЛЕНИЕ:

• Изменено return null to throw new IllegalArgumentException (record);
• Чтобы уточнить, есть три причины, по которым простого метода RecordType.process () будет недостаточно: во-первых, обработка действительно слишком далеко от RecordType, чтобы заслужить ее собственный метод в подклассах RecordType. Кроме того, существует множество различных типов обработки, которые теоретически могут выполняться разными процессорами. Наконец, RecordType разработан как простой класс DTO с минимальными методами изменения состояния, определенными внутри.