Является ли хорошей практикой частое использование instanceof?

Допустим, я пишу инвентарный код:

public void showInventory(List<Item> items) {
    for (Item item : items) {
        if (item instanceof ContainerItem) {
            // container display logic here
        }
        else if (item instanceof WeaponItem) {
            // weapon display logic here
        }
        // etc etc
    }
}

Это будет компилироваться и работать нормально. Но он упускает из виду ключевую идею объектно-ориентированного дизайна: Вы можете определить родительские классы для выполнения общих полезных вещей, а дочерние классы будут заполнять конкретные важные детали.

Альтернативный подход к вышеуказанному:

abstract class Item {
    // insert methods that act exactly the same for all items here

    // now define one that subclasses must fill in themselves
    public abstract void show()
}
class ContainerItem extends Item {
    @Override public void show() {
        // container display logic here instead
    }
}
class WeaponItem extends Item {
    @Override public void show() {
        // weapon display logic here instead
    }
}

Теперь у нас есть одно место, метод show(), во всех наших дочерних классах для логики отображения инвентаря. Как нам получить к нему доступ? Легкий!

public void showInventory(List<Item> items) {
    for (Item item : items) {
        item.show();
    }
}

Мы сохраняем всю логику, относящуюся к конкретным элементам, внутри определенных подклассов элементов. Это упрощает поддержку и расширение вашей кодовой базы. Это снижает когнитивную нагрузку на длинный цикл for-each в первом примере кода. И он готов show() к повторному использованию в местах, которые вы еще даже не проектировали.

ИМХО использование instanceof - это запах кода. Проще говоря, это делает ваш код процедурным, а не объектно-ориентированным. ОО способ сделать это - использовать шаблон посетителя.

Шаблон посетителя также позволяет вам легко создавать decorator и chain of responsibility поверх него, тем самым достигая разделения задач, что приводит к более короткому, чистому и удобному для чтения и тестирования коду.

Также вам действительно нужно знать точный класс? Не можете воспользоваться полиморфизмом? В конце концов, Axe ЯВЛЯЕТСЯ Weapon так же, как Sword.

Вам следует переосмыслить, может быть, и попытаться использовать полиморфизм для реализации вашей List<Item> идеи.

Вот несколько ссылок на вашу проблему, которые, вероятно, могут помочь:

• Предпочитайте полиморфизм instanceof и понижающего преобразования
• instanceof против getClass в методах equals (интервью с Джошем Блохом)
• Полиморфизм и интерфейсы (см. раздел о том, когда использовать instanceof)

(Ссылки из Считается ли instanceof плохой практикой? ? Если да, то при каких обстоятельствах instanceof по-прежнему предпочтительнее?)

Вам следует переосмыслить свою структуру, instanceof в немета-коде почти всегда является признаком анти-паттерна. Попытайтесь определить поведение, общее для всех Item (например, наличие изображения, описания и чего-то, что происходит, когда вы нажимаете на них) в Item-классе / интерфейсе, используя abstract-ключевое слово, если это уместно, а затем используйте полиморфизм, чтобы реализовать особенности.

Ничего страшного, если тебе легко понять.

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

В конце концов, все дело в том, как физически организовать наш код с несколькими измерениями задач в одномерном пространстве. Это нетривиальная проблема, это субъективно, и панацеи нет.

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

Некоторые из этих правил могут больше не применяться сегодня.

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

С учетом сказанного, предоставленное вами описание не требует instanceof. Есть разные способы реализовать это без instanceof, и (самое главное) альтернативное решение должно быть лучше, чем использование instanceof. Не используйте решение, отличное от instanceof, чтобы избежать instanceof, потому что вы слышали, что это плохо.

Я думаю, что для вашего сценария решение, отличное от instanceof, имеет преимущества в том, что решение становится более легко расширяемым.

for (Item i: items) {
    if (ItemTypes.WEAPON_ITEM.equals(i.getType)) {
        processWeaponType(i);
    }

}

or

for (Item i: items) {
    if (WeaponItem.class.equals(i.getType)) {
        processWeaponType(i);
    }

}