Будь-яка причина віддати перевагу getClass () над instanceof при генерації .equals ()?

Я використовую Eclipse , для створення .equals()і .hashCode(), і є варіант з написом «Використовувати" InstanceOf "для порівняння типів». За замовчуванням ця опція не знімається та використовується .getClass()для порівняння типів. Чи є якийсь - небудь причини я вважаю за краще .getClass()більш instanceof?

Без використання instanceof:

if (obj == null)
  return false;
if (getClass() != obj.getClass())
  return false;

Використання instanceof:

if (obj == null)
  return false;
if (!(obj instanceof MyClass))
  return false;

Я зазвичай перевіряю instanceofпараметр, а потім заходжу та знімаю if (obj == null)чек. (Це зайве, оскільки нульові об'єкти завжди будуть виходити з ладу instanceof.) Чи є причина, що це погана ідея?

Якщо ви використовуєте instanceof, роблячи вашу equalsреалізацію finalзбереже контракт симетрії методу: x.equals(y) == y.equals(x). Якщо вам finalздається обмежувальним, уважно вивчіть своє поняття еквівалентності об'єкта, щоб переконатися, що ваші переважні реалізації повністю підтримують контракт, встановлений Objectкласом.

Джош Блох виступає за ваш підхід:

Причиною того, що я віддаю перевагу instanceofпідходу, є те, що при використанні getClassпідходу у вас є обмеження, що об'єкти рівні лише іншим об'єктам того ж класу, того ж типу часу виконання. Якщо ви розширите клас і додасте до нього пару нешкідливих методів, то перевірте, чи є якийсь об'єкт підкласу рівним об’єкту надкласового класу, навіть якщо об'єкти рівні у всіх важливих аспектах, ви отримаєте дивна відповідь, що вони не рівні. Насправді це порушує суворе тлумачення принципу заміни Ліскова і може призвести до дуже дивної поведінки. Для Java це особливо важливо, оскільки більшість колекцій (HashTableтощо) засновані на методі рівних. Якщо ви помістите члена суперкласу в хеш-таблицю як ключ, а потім шукаєте його за допомогою екземпляра підкласу, його ви не знайдете, оскільки вони не рівні.

Дивіться також цю відповідь ТА .

Ефективна глава 3 розділу Java також охоплює це.

Анжеліка Лангерс " Секрети рівних" потрапляє в цю історію з довгим і детальним обговоренням декількох поширених і відомих прикладів, зокрема Джоша Блоха та Барбари Ліськов, виявивши кілька проблем у більшості з них. Вона також потрапляє в instanceofпроти getClass. Деякі цитати з нього

Висновки

Розділивши чотири довільно обрані приклади реалізації рівностей (), що ми робимо?

Перш за все: є два суттєво різні способи виконання перевірки відповідності типу в реалізації рівняння (). Клас може дозволяти зіставляти змішані типи об’єктів над- і підкласу за допомогою оператора instanceof, або клас може розглядати об'єкти іншого типу як нерівні за допомогою тесту getClass (). Наведені вище приклади добре проілюстрували, що реалізація рівнянь () за допомогою getClass (), як правило, більш надійна, ніж ті, що реалізують, використовуючи instanceof.

Тест instanceof є правильним лише для підсумкових класів або, якщо принаймні метод дорівнює (), є остаточним у суперкласі. Останній по суті означає, що жоден підклас не повинен поширювати стан надкласу, а може додавати лише функціональність або поля, які не мають значення для стану та поведінки об'єкта, наприклад, перехідні або статичні поля.

Реалізація, що використовує тест getClass (), з іншого боку, завжди відповідає договору equals (); вони правильні та надійні. Однак вони семантично дуже відрізняються від реалізацій, які використовують тест instanceof. Реалізації, що використовують getClass (), не дозволяють порівнювати під- з об'єктами надкласового класу, навіть коли підклас не додає жодних полів і навіть не хотів би замінити рівняння (). Таке "тривіальне" розширення класу, наприклад, було б додаванням методу друку налагодження у підкласі, визначеному саме для цієї "тривіальної" мети. Якщо суперклас забороняє порівняння змішаного типу через перевірку getClass (), то тривіальне розширення було б не порівнянне з його суперкласом. Чи повністю це проблема чи ні, залежить від семантики класу та мети розширення.

Підставою для використання getClassє забезпечення симетричної властивості equalsдоговору. З рівних JavaDocs:

Він симетричний: для будь-яких ненульових опорних значень x і y, x.equals (y) має повертати істину, якщо і лише тоді, коли y.equals (x) повертає істинне.

Використовуючи instanceof, можна не бути симетричним. Розглянемо приклад: Собака розтягує Тварину. Animal's equalsробить instanceofперевірку на Animal. Собака equalsробить instanceofперевірку Собаки. Дайте тварині a та собаці d (з іншими полями те саме):

a.equals(d) --> true
d.equals(a) --> false

Це порушує симетричну властивість.

Щоб суворо дотримуватись контракту рівних, повинна бути забезпечена симетрія, і, отже, клас повинен бути однаковим.

Це щось із релігійної дискусії. Обидва підходи мають свої проблеми.

• Використовуйте instanceof, і ви ніколи не можете додавати значних членів до підкласів.
• Використовуйте getClass і ви порушуєте принцип заміни Ліскова .

У Bloch є ще одна відповідна порада в Ефективній Java Second Edition :

• Пункт 17: Проектувати та документувати спадщину або забороняти це

Виправте мене, якщо я помиляюся, але getClass () буде корисний, коли ви хочете, щоб ваш екземпляр НЕ був підкласом класу, з яким ви порівнюєте. Якщо ви використовуєте instanceof у цій ситуації, ви НЕ можете цього знати, оскільки:

class A { }

class B extends A { }

Object oA = new A();
Object oB = new B();

oA instanceof A => true
oA instanceof B => false
oB instanceof A => true // <================ HERE
oB instanceof B => true

oA.getClass().equals(A.class) => true
oA.getClass().equals(B.class) => false
oB.getClass().equals(A.class) => false // <===============HERE
oB.getClass().equals(B.class) => true

Якщо ви хочете переконатися, що відповідатиме лише той клас, тоді використовуйте getClass() ==. Якщо ви хочете відповідати підкласам, тоді instanceofце потрібно.

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

if ( ! (obj instanceof MyClass) ) { return false; }

Це залежить, якщо врахувати, чи підклас даного класу дорівнює його батьківському.

class LastName
{
(...)
}


class FamilyName
extends LastName
{
(..)
}

тут я б використав 'instanceof', тому що я хочу, щоб LastName порівнювався з FamilyName

class Organism
{
}

class Gorilla extends Organism
{
}

тут я б використав 'getClass', тому що клас вже говорить, що два екземпляри не рівноцінні.

instanceof працює на погляди того ж класу або його підкласів

Ви можете використовувати його для перевірки, чи об'єкт є екземпляром класу, екземпляром підкласу або екземпляром класу, який реалізує певний інтерфейс.

ArryaList і RoleList - це інстанції List

Поки

getClass () == o.getClass () буде істинним лише в тому випадку, якщо обидва об'єкти (це та o) належать точно до одного класу.

Тож залежно від того, що вам потрібно порівняти, ви могли використовувати те чи інше.

Якщо ваша логіка: "Один об'єкт дорівнює іншим, лише якщо вони обидва того ж класу", ви повинні перейти до "рівних", що, на мою думку, є більшістю випадків.

Обидва методи мають свої проблеми.

Якщо підклас змінює ідентичність, то вам потрібно порівняти їхні фактичні класи. В іншому випадку ви порушите симетричну властивість. Наприклад, різні типи Persons не повинні вважатися еквівалентними, навіть якщо вони мають однакове ім'я.

Однак деякі підкласи не змінюють ідентичність, і їх потрібно використовувати instanceof. Наприклад, якщо у нас є купа незмінних Shapeоб'єктів, то Rectangleдовжина і ширина 1 повинні дорівнювати одиниці Square.

На практиці я вважаю, що колишній випадок швидше правдивий. Зазвичай, підкласифікація є фундаментальною частиною вашої особистості, і саме так, як ваш батько, за винятком того, що ви можете зробити одну дрібницю, не зробите вас рівними.

Насправді випадки перевірки, де об'єкт належить до якоїсь ієрархії чи ні. наприклад: Об'єкт автомобіля належить до класу "Транспорт". Тож "новий екземпляр автомобіля") повертає істину. І "новий автомобіль (). GetClass (). Дорівнює (Vehical.class)" повертає помилкове значення, хоча об'єкт "Автомобіль" належить до класу "транспортні засоби", але його віднесено до окремого типу.