Czy jest jakiś powód, aby preferować metodę getClass () zamiast instanceof podczas generowania .equals ()?

Używam Eclipse do generowania .equals()i .hashCode(), i jest opcja oznaczona jako „Użyj„ instanceof ”, aby porównać typy”. Domyślnie ta opcja jest odznaczona i używana .getClass()do porównywania typów. Czy jest jakiś powód powinien Wolę .getClass()ponad instanceof?

Bez użycia instanceof:

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

Używając instanceof:

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

Zwykle zaznaczam instanceofopcję, a następnie wchodzę i usuwam if (obj == null)zaznaczenie. (Jest to zbędne, ponieważ puste obiekty zawsze zawodzą instanceof). Czy jest jakiś powód, dla którego to zły pomysł?

Jeśli używasz instanceof, dzięki czemu equalswdrażanie finalzachowa umowę symetrii metody: x.equals(y) == y.equals(x). Jeśli finalwydaje się to restrykcyjne, dokładnie przeanalizuj swoje pojęcie równoważności obiektów, aby upewnić się, że nadpisujące implementacje w pełni obsługują kontrakt ustanowiony przez Objectklasę.

Josh Bloch popiera Twoje podejście:

Powodem, dla którego preferuję to instanceofpodejście, jest to, że kiedy używasz tego getClasspodejścia, masz ograniczenie, że obiekty są równe tylko innym obiektom tej samej klasy, tego samego typu czasu wykonywania. Jeśli rozszerzysz klasę i dodasz do niej kilka nieszkodliwych metod, a następnie sprawdź, czy jakiś obiekt podklasy jest równy obiektowi superklasy, nawet jeśli obiekty są równe we wszystkich ważnych aspektach, otrzymasz zaskakująca odpowiedź, że nie są sobie równi. W rzeczywistości narusza to ścisłą interpretację zasady substytucji Liskova i może prowadzić do bardzo zaskakującego zachowania. W Javie jest to szczególnie ważne, ponieważ większość kolekcji (HashTableitp.) opierają się na metodzie równości. Jeśli umieścisz członka superklasy w tablicy skrótów jako klucz, a następnie sprawdzisz go za pomocą instancji podklasy, nie znajdziesz go, ponieważ nie są równe.

Zobacz także tę odpowiedź SO .

Efektywna Java rozdział 3 również to obejmuje.

Angelika Langers Tajemnice równości wkraczają w to po długiej i szczegółowej dyskusji kilku popularnych i dobrze znanych przykładów, w tym autorstwa Josha Blocha i Barbary Liskov, odkrywając w większości z nich kilka problemów. Wstaje również Into the instanceofvs getClass. Jakiś cytat z tego

Wnioski

Po przeanalizowaniu czterech arbitralnie wybranych przykładów implementacji równości (), do czego dochodzimy?

Po pierwsze: istnieją dwa zasadniczo różne sposoby przeprowadzania sprawdzenia zgodności typu w implementacji equals (). Klasa może umożliwiać porównywanie typów mieszanych między obiektami super- i podklas za pomocą operatora instanceof lub klasa może traktować obiekty różnego typu jako nierówne za pomocą testu getClass (). Powyższe przykłady dobrze ilustrują, że implementacje equals () przy użyciu metody getClass () są generalnie bardziej niezawodne niż implementacje używające instancji instanceof.

Instancja testu jest poprawna tylko dla klas końcowych lub jeśli przynajmniej metoda equals () jest ostateczna w nadklasie. To ostatnie zasadniczo oznacza, że ​​żadna podklasa nie może rozszerzać stanu nadklasy, ale może dodawać tylko funkcje lub pola, które nie mają znaczenia dla stanu i zachowania obiektu, takie jak pola przejściowe lub statyczne.

Z drugiej strony implementacje używające testu getClass () zawsze są zgodne z kontraktem equals (); są poprawne i solidne. Są jednak semantycznie bardzo różne od implementacji, które używają testu instanceof. Implementacje używające getClass () nie pozwalają na porównywanie podklasy z obiektami nadklasy, nawet jeśli podklasa nie dodaje żadnych pól i nie chce nawet przesłonić równań (). Takim „trywialnym” rozszerzeniem klasy byłoby na przykład dodanie metody debug-print w podklasie zdefiniowanej dokładnie dla tego „trywialnego” celu. Jeśli nadklasa zabrania porównywania typów mieszanych za pomocą sprawdzenia getClass (), to trywialne rozszerzenie nie byłoby porównywalne z jego nadklasą. To, czy jest to problem, w pełni zależy od semantyki klasy i celu rozszerzenia.

Celem stosowania getClassjest zapewnienie symetryczności equalsumowy. Z równych dokumentów JavaDocs:

Jest symetryczny: dla wszelkich niezerowych wartości odniesienia xiy, x.equals (y) powinno zwracać prawdę wtedy i tylko wtedy, gdy y.equals (x) zwraca prawdę.

Używając instanceof, można nie być symetrycznym. Rozważmy przykład: Pies rozszerza Animal. Zwierzęcia equalsrobi się instanceofkontrolę zwierzęcia. Psa equalsrobi to instanceofsprawdzenie Dog. Daj Zwierzę a i Pies d (z innymi polami to samo):

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

Narusza to właściwość symetrii.

Aby ściśle przestrzegać kontraktu równego, należy zapewnić symetrię, a zatem klasa musi być taka sama.

To coś w rodzaju debaty religijnej. Oba podejścia mają swoje problemy.

• Użyj instanceof i nigdy nie możesz dodawać ważnych członków do podklas.
• Użyj getClass i naruszysz zasadę zastępowania Liskova .

Bloch ma kolejną istotną radę w Effective Java Second Edition :

• Punkt 17: Zaprojektuj i udokumentuj dziedziczenie lub zakazaj tego

Popraw mnie, jeśli się mylę, ale metoda getClass () przyda się, gdy chcesz się upewnić, że Twoja instancja NIE jest podklasą klasy, z którą porównujesz. Jeśli używasz w takiej sytuacji instanceof, NIE możesz tego wiedzieć, ponieważ:

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

Jeśli chcesz mieć pewność, że tylko ta klasa będzie pasować, użyj getClass() ==. Jeśli chcesz dopasować podklasy, instanceofjest to potrzebne.

Ponadto instanceof nie pasuje do wartości null, ale można ją bezpiecznie porównać z wartością null. Więc nie musisz tego sprawdzać.

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

Zależy to od tego, czy weźmiesz pod uwagę, czy podklasa danej klasy jest równa swojej klasie macierzystej.

class LastName
{
(...)
}


class FamilyName
extends LastName
{
(..)
}

tutaj użyłbym „instanceof”, ponieważ chcę, aby LastName był porównywany z FamilyName

class Organism
{
}

class Gorilla extends Organism
{
}

tutaj użyłbym „getClass”, ponieważ klasa mówi już, że te dwa wystąpienia nie są równoważne.

instanceof działa dla instancji tej samej klasy lub jej podklas

Można go użyć do sprawdzenia, czy obiekt jest instancją klasy, instancją podklasy lub instancją klasy implementującej określony interfejs.

ArryaList i RoleList są instancjami listy

Podczas

getClass () == o.getClass () będzie prawdziwe tylko wtedy, gdy oba obiekty (this i o) należą do dokładnie tej samej klasy.

Więc w zależności od tego, co chcesz porównać, możesz użyć jednego lub drugiego.

Jeśli Twoja logika brzmi: „Jeden obiekt jest równy drugiemu tylko wtedy, gdy oba należą do tej samej klasy”, powinieneś wybrać „równe”, co moim zdaniem jest w większości przypadków.

Obie metody mają swoje problemy.

Jeśli podklasa zmieni tożsamość, musisz porównać ich rzeczywiste klasy. W przeciwnym razie naruszysz właściwość symetrii. Na przykład różne typy Personznaków nie powinny być uważane za równoważne, nawet jeśli mają taką samą nazwę.

Jednak niektóre podklasy nie zmieniają tożsamości i trzeba ich używać instanceof. Na przykład, jeśli mamy kilka niezmiennych Shapeobiektów, to a Rectangleo długości i szerokości 1 powinno być równe jednostce Square.

W praktyce myślę, że ten pierwszy przypadek jest bardziej prawdopodobny. Zwykle tworzenie podklas jest fundamentalną częścią twojej tożsamości, a bycie dokładnie takim jak twój rodzic, z wyjątkiem jednej małej rzeczy, nie czyni cię równym.

Właściwie instancja sprawdzenia, czy obiekt należy do jakiejś hierarchii, czy nie. np .: obiekt samochodowy należy do klasy pojazdów. Zatem „new Car () instancja klasy Vehical” zwraca wartość true. A „new Car (). GetClass (). Equals (Vehical.class)” zwraca false, chociaż obiekt Car należy do klasy Vehical, ale jest sklasyfikowany jako oddzielny typ.