Dlaczego klasa abstrakcyjna może wymusić zastąpienie konkretnej metody?

Question

używam biblioteki gdzie klasa abstrakcyjna zasłania konkretną metodę odziedziczoną Object z abstrakcyjnej metody:

public abstract class A { 
    @Override 
    public abstract boolean equals(Object obj); 
} 

przedłużyć tę klasę, trzeba zaimplementować metodę equals:

public class B extends A { 
    @Override 
    public boolean equals(Object obj) { 
     return obj != null && obj.getClass() == B.class; 
    } 
} 

---

Dlaczego metoda abstrakcyjna (A::equals) zastępuje konkretną metodę (Object::equals)? Nie widzę tego celu.

Answer 1

W tym konkretnym przykładzie ma to sens. Jeśli podklasy A mają być używane w kolekcjach, gdzie equals jest powszechnie używany do lokalizowania obiektów, abstrakcyjne metody A wymuszają podanie domyślnej implementacji equals w dowolnej podklasie A (zamiast przy użyciu domyślnej implementacji klasy Object, która tylko porównuje odwołania do instancji).

Oczywiście sugerowana implementacja equals w B nie ma większego sensu. Powinieneś porównywać właściwości wystąpień 2 B, aby określić, czy są one równe.

To jest bardziej odpowiednia realizacja:

public class B extends A { 
    @Override 
    public boolean equals(Object obj) { 
     if (!(obj instanceof B)) 
      return false; 
     B other = (B) obj; 
     return this.someProperty.equals(other.someProperty) && this.secondProperty.equals(other.secondProperty); 
    } 
} 

Ponadto, należy pamiętać, aby zastąpić hashCode ilekroć przesłonić equals (od umowy equals i hashCode wymaga, że ​​jeśli a.equals(b) == true następnie a.hashCode() == b.hashCode()).

Answer 2

Ponieważ w tym przypadku użytkownik chciałby, aby obiekty definiowały własne obiekty equals, które podobno będą działać inaczej niż domyślna implementacja.

Nie należy patrzeć na to jako na funkcję , usuwając funkcję, ale raczej na wymuszanie, że dziedziczące obiekty implementują własne.

Answer 3

Umożliwia to wymuszenie podklasy w celu ponownego zastosowania metody. Czy to dobry pomysł, czy nie, to inna kwestia. Zrobiłbyś to tylko, gdybyś chciał egzekwować silniejszą umowę niż dostarczona oryginalna metoda. Następnie należy starannie udokumentować nową umowę.

Answer 4

Oznacza to, że musi zaimplementować własną equals() metodę

Answer 5

Ponieważ wszystkie klasy w Javie natury rozszerzyć klasę Object. Klasa A będzie dziedziczyć metodę Object#equals. Załóżmy, że chcesz wymusić błąd kompilacji, gdy metoda równań nie jest jawnie zaimplementowana, tak jak w tym example. Wykonanie abstrakcyjnej metody równań bez bloku implementacji umożliwiłoby to wykonanie.