Если не изменяет память то всё что попадает в Object - теряет свой тип. Поэтому при «доставании» из Object необходимо указывать что именно достаёшь(какой именно тип).
С точки зрения тебя - да, ты определил.
С точки зрения компилятора - ты просто вызвал пару геттеров и equals.
Сужающие приведения компилятор джавы сам не делает, у джавы статическая сильная(в основном) типизация, ему нужно явно сказать - трактуй этот объект как объект такого то типа. А хотелось бы иметь доступ к методам более узкого объекта, а не только общим для всех объектов.
В 16-ой джаве, вроде, можно сразу проверить тип и привести.
Как интерпретировать объект зависит от типа переменной. Переменная единожды объявленна как Object свой тип поменять не может.
В 16-ой джаве, вроде, можно сразу проверить тип и привести.
Здесь не тот случай.
В Java 16 "автоприведение" типа сделано только для оператора instanceof, а он, для применения в методе equals(), имхо, подходит слабо.
Ну, идея при автогенерации иквалза таки использует instanceof. И только потом конкретный класс проверяет.
Есть ли в этом смысл? Не знаю
Может там оптимизации какие-то есть.
Но фича автокаста там не применима, согласен.
Но разве тогда не возможна ситуация нарушающая контракт equals()?
Ведь если для установления подходящего типа объекта используется только instanceof, то легко представить случай, когда в классе-потомке метод equals() переопределён, например для учёта добавочных полей, и тогда возможен случай, что сравнение экземпляра класса-предка с экземпляром класса-потомка даст true, а наоборот - false.
Но разве тогда не возможна ситуация нарушающая контракт equals()?
а использование getClass нарушает принцип подстановки Барбары Лисков.
то легко представить случай,
а что его представлять)
тут будет true
на то программистам и дана голова, чтобы думать что с чем где он сравнивает. ты же не Object везде пихаешь, а пишешь вполне осознанный код.
ну и есть ещё разные варианты для безопасного расширения классов.
Я не говорю что писать надо только так и точка. я лишь передал мнение Блоха по правильности написания equals() и он вполне себе аргументировал в книге почему он считает это более правильным инструментом, а не == null || != getClass
То есть я правильно понимаю, что даже если на входе будет объект типа Person, он будет считываться компилятором как объект типа Object, т.к входной параметр у нас указан как тип Object?
В рамках локального скоупа метода - да.
У тебя ведь тип аргумента ничем не ограничем. В рантайме туда может прийти что угодно.
Соответственно компилятор не может знать что именно туда прилетит.
instanceof
, а он, для применения в методеequals()
, имхо, подходит слабо.equals()
? Ведь если для установления подходящего типа объекта используется толькоinstanceof
, то легко представить случай, когда в классе-потомке методequals()
переопределён, например для учёта добавочных полей, и тогда возможен случай, что сравнение экземпляра класса-предка с экземпляром класса-потомка дастtrue
, а наоборот -false
.