У меня есть коллега здесь, в моем проекте, который глубоко против использования оператора instanceof, потому что он "генерирует много накладных расходов", в чем причина этого? Это правда?
Есть ли другой способ проверить тип объекта вместо его использования?
Потому что я нахожу его очень полезным в некоторых случаях.
Он генерирует некоторые накладные расходы в сочетании с последующим литьем. С последней версией Java накладные расходы уменьшились. Но в любом случае это микрооптимизация - то есть вы не должны беспокоиться об этом в общем случае.
Реальный аргумент против instanceof заключается в том, что во многих случаях существуют лучшие способы ООП для достижения желаемого поведения.
Он может или не может генерировать какие-либо накладные расходы, если компилятор может доказать экземпляр. Даже если компилятор не может сразу доказать цель, накладные расходы очень малы. Несколько часов процессора (особенно, если instanceof jump правильно предсказано).
Следующие роли после экземпляра обычно бесплатны.
(примечание: компилятором я имею в виду JIT)
Нет серьезных накладных расходов. Это почти наверняка дешевле, чем самодельное решение getType(). Кастинг, хотя и не бесплатный, также очень дешев.
Как отметил Божо, это может показаться ошибочным дизайном, но в некоторых ситуациях это самый прагматичный выбор, и поэтому его нельзя игнорировать из-под контроля.
Основная проблема заключается в том, что он генерирует запах кода. Если вы используете полиморфизм, это лучший подход к разработке. Стоимость выполнения может составлять от 10 до 100 наносекунд в зависимости от сложности вызова и от того, сколько методов реализации вы вызываете из этой строки кода.
Фактически, instanceof возвращает true, а приведение к этому типу завершается не полностью эквивалентно - последнее может преуспеть, если первое возвращает false. Итак, даже когда есть что-то подобное,
String s = someMethodReturningString();
Object o = s;
if (o instanceof String) {
...
}
компилятор должен сгенерировать хотя бы проверку o != null здесь.
На практике это пренебрежимо.