Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
Das kommt ganz darauf an, wann du zwei Objekte als "gleich" betrachtest.
Manchmal kann dies zu wenig sein, manchmal ist dies auch zu viel.
Sind zwei Personen, die als member "vorname" den wert "Peter" und als member "nachname" den Wert "Maier" haben, wirklich gleich?
Umgekehrt können zwei Personen gleich sein, obwohl die eine den Vornamen "Klaus" und die andere den Vornamen "Klaus Heinrich" hat.
Wenn du also die Methode "equals(Object o)" überschreibst, musst du wissen, was du willst.
Um zur bestehenden Antwort hinzuzufuegen, ja, man muss alles vergleichen was zur Gleichheit gehoert. Du solltest auch "hashCode" ueberschreiben wenn du "equals" ueberschreibst, denn es gibt den Vertrag dass wenn "a.equals(b) == true" ist, dass dann auch "a.hashCode() == b.hashChode() == true" ist. Siehe die Javadoc von "Object.equals". Das ist insofern wichtig als dass viele Klassen davon ausgehen dass dem der Fall ist, am wichtigstens hierbei ist "HashMap". Ich glaube du erhaeltst undefiniertes Verhalten wenn "equals" und "hashCode" nicht symmetrisch sind von dem Objekt welches in die HashMap hinzugefuegt wird.
Viele IDEs erlauben dir "equals" und "hashCode" zu generieren in dem du die Felder auswaehlst welche du willst, das hilft immer wieder wenn man nicht alles tippen muss. Wenn du uebertreiben willst, kannst du dir ein Hilfs-Util schreiben welches Reflection verwendet um "equals" und "hashCode" zu implementieren, aber da sind wir schon fast im esoterischen Bereich mit sehr speziellen Anwendungsfaellen.
Mir kommt es auf die Inhalte an.
Es sind Klassen die Daten enthalten.
Wenn die Member des gleichen Objekts, name und alter sind
und O1 - Peter / 7
und O2 - Peter / 9
und O3 - Peter / 7 enthalten.
dann soll das Ergebnis sein
O1 verglichen mit O2 falsch
O1 verglichen mit O3 richtig sein.
Mir gehts dabei um den Aufand.
Ich kann natürlich jeden Member des Objekts vergleichen, muss dabei aber auch die Datentypen berücksichtigen.
Schöner wäre es wenn dieser Vergleich automatisch mithilfe einer Klasse durchgeführt würde.
Die Klasse müsste dann die Members für sich einlesen und dann entsprechend dem Datentyp vergleichen.
Ich habe auch schon darüber nachgedacht diese Klasse selber zu schreiben, weiß aber nicht wie ich bei beliebigen Klassen die Members auslesen kann und dann die Datentypen für den Vergleich ermitteln kann.
Du kannst das natürlich per Reflection machen - aber das ist von der Laufzeit ungünstig und auch vom Aufwand nicht empfehlenswert.
Oder Du arbeitest mit Anotations und lässt dann generieren, was Du brauchst. Wenn Du Code generierst, dann ist die Laufzeit wieder super, aber die IDE weiss ja nicht, was Du generierst.
Ein Beispiel für letzteres ist z.B. Lombok. Und damit die IDEs damit klar kommen, gibt es AddOns für die gängigen IDEs.
Ich habe auch schon darüber nachgedacht diese Klasse selber zu schreiben, weiß aber nicht wie ich bei beliebigen Klassen die Members auslesen kann und dann die Datentypen für den Vergleich ermitteln kann.
Ich habe es "schon fast esoterisch" genannt weil es das ist, so wie @kneitzel sagt kann es um ein vielfaches komplizierter werden als die equals einfach zu schreiben. Wenn du nicht gerade 500 Datenklassen hast, wuerde ich auch dazu raten "equals" einfach zu tippen, es ist einfach simpler und besser zu warten.
Es ist eigentlich recht einfach eine Funktion zu schreiben welche die Member vergleicht, geraten ohne es getestet zu haben:
Java:
for (Field field : getClass().getDeclaredFields()) {
if (!Objects.equals(field.invoke(this), field.invoke(otherInstance)) {
return false;
}
}
return true;
Das Komplizierte erreichst du dann wenn du "nur diese drei von allen fuenf Feldern" willst. Weil wie unterscheidest du das? Nach Namen? Annotation? Liste an Namen? Da wird es schnell haesslich, kompliziert und Fehleranfaellig. Daher, ich finde "von der IDE generieren lassen" einen recht guten Ansatz wenn man es nicht tippen will.
Eine wichtige Frage hierbei ist auch "wie oft wird sich die Logik von dieser equals aendern". Wenn du alle naselang mal Felder hinzufuegst und wegnimmst, kann eine dynamische Methode ueber Reflection ganz interessant sein. Wenn sich diese Klassen nie wieder veraendern, ist es meistens besser die equals vollstaendig implementiert zu haben, weil sich dann zumindest Fehlersuche einfacher gestaltet.
Ich habe das Problem für die Masse der Klassen umgangen, indem ich eine MemberVariable beim Update setze.
Damit ist klar, da hat sich was geändert.
(Ich mach das Update nur wenn sich ein Inhalt ändert und brauche die Info ob sich etwas verändert hat für ein Protokoll.)
In einer Klasse musste ich dann aber doch den Klasseninhalt vergleichen.
Da habe ich dann auf die getter zugegriffen und es dafür geschrieben.