Und zwar soll Gleichheit bedeuten, dass alle Felder die gleichen Werte enthalten. Gibt es da irgendwie eine Funktion dafür oder ein Framework? Denn eigentlich muss das ja rekursiv laufen.

Edit: Ich benutze Java. CRegenschein schrieb etwas zu Reflection. Gibt es dafür ein Beispiel?

Mit Reflection ist das sicherlich möglich, falls Deine Programmiersprache das bietet.
Java und C# usw. können das wohl, aber für ein konkretes Beispiel müsstest Du noch mitteilen, in welcher Sprache das geschehen soll

Grüße
CRegenschein

Ausgehend, dass du den Quellcode hast, würde ich für die Klasse einen Operator überladen, der die Gleichheit oder Ungleichheit testet. Dann weißt du nämlich, welche Felder du hast und somit vergleichen musst.
Wenn du den Code nicht hast, musst du mit Reflection arbeiten, wie CRegenschein richtig sagt.

Das sehe ich genauso, du kannst in Java ebenfalls die equals-Methode überschreiben.

Ich würde das auch in die equals Methode integrieren. Habe aber noch einen Tipp um Programmierarbeit zu sparen. Im Apache Package commons-beanutils gibt es die Klasse org.apache.commons.beanutils.BeanComparator
Die kannst du nutzen um per Reflections API 2 Beans zu vergleichen.

Natürlich nur, wenn du Java als Programmiersprache verwendest. Ich bin mir aber sicher das es so etwas ähnliches in .Net und anderen Sprachen auch geben wird.

EqualsBuilder.reflectionEquals von Commons Lang macht das:

http://commons.apache.org/lang/api-2.4/org/apache/commons/lang/builder/EqualsBuilder.html#reflectionEquals%28java.lang.Object,%20java.lang.Object%29

Würde stark empfehlen auf die Implementierung der Methode equals zu setzen, denn die Klasse selbst weiß am besten wann zwei Instanzen davon gleich sind. Zusammen mit hashCode wird diese Methode auch vom Collections-Framework verwendet.

Die Frage ist sehr abstrakt, sodass es schwierig ist, konkret darauf zu antworten.

Das Überschreiben der equals-Methode ist sicherlich die beste Wahl, wenn die Anzahl der zu vergleichenden Objektvariablen drei nicht überschreitet. Um diese Richtlinie einzuhalten, auch wenn es mehr Variablen gibt, die zu vergleichen sind, kann man Objekte unterschiedlichen Typs komponieren, um den Vergleich pro Typ klein zu halten.

Grundsätzlich hat man eh ein Granularitätsproblem, wenn ein Objekt einer Klasse mehr als zehn Objektvariablen besitzt, die dann auch noch die Identität darstellen. Ich kenne den Anwendungsfall nicht, aber unter der genannten Bedingung sollte das Design überdacht werden.

Die Verwendung von Apache Commons EqualsBuilder scheint nützlich. Es muss aber klar sein, was EqualsBuilder macht und ob das Verhalten in jedem Fall gewünscht ist. Ich lehne solche generischen Mechanismen für die Einbindung in ein Fachmodell ab. Generische Implementationen haben nur etwas im Fachmodell zu suchen, wenn sie Typsicherheit produzieren. Ansonsten sind diese Mechanismen Framework-Entwicklern vorrzubehalten, da diese häufig nicht wissen, mit welchen konkreten Objekten sie es zu tun haben werden.

Falls Du die equals-Methode überschreibst, ist es ebenfalls sinnvoll die hashCode-Methode zu überschreiben. Die JAVA-Richtlinien legen dies sogar fest, da in vielen Kontexten hashCode verwendet wird, um schnellen assoziativen Zugriff auf Objekte zu realisieren.

Das Überschreiben von equals und hashCode ist nicht ganz unkritisch. Deshalb halte dies sehr einfach. Zusätzlich ist zu beachten, dass die mit equals zu vergleichenden Objektvariablen immutable (unveränderbar) sind, falls die Objekte in hashCode-nutzende Mengen und Listen verarbeitet werden. Objekte, deren Identitäts-Variablen nachträglich geändert werden, werden in hashCode-nutzenden Mengen und Listen nicht wiedergefunden, was zu nicht nachvollziehbaren Seiteneffekten führen kann. Am besten ist es für die Identitätsvariablen keine Setter anzubieten, was natürlich bedeutet, dass deine Objekte KEINE Beans sein dürfen.

Hier ein Beispiel:

class A {

   private String x;
   private B b;

   public A (String x, B b) {
      this.x = x;
      this.b = b;
   }

   @Override
   public boolean equals(Object o) {
      boolean equals = false;
      if (o instanceof A) {
         A that = (A) o;
         equals = this.x.equals(that.x) && this.b.equals(that.b);
      }
      return equals;
   }

   @Override
   public int hashCode() {
      return this.x.hashCode() * this.b.hashCode();
   }

}

public class B {
   
   private String y;

   public B (String y) {
      this.y = y;
   }

   @Override
   public boolean equals(Object o) {
      boolean equals = false;
      if (o instanceof B) {
         B that = (B) o;
         equals = this.y.equals(that.y);
      }
      return equals;
   }

   @Override
   public int hashCode() {
      return this.y.hashCode();
   }

}

Die equals-Methoden sind nicht null-safe. Aber da wir ja nie null zurückgeben und auch nie übergeben erübrigt sich dies, denn null smells horrible...

Solltest Du doch Reflection verwenden und das Gießkannenprinzip anwenden wollen, rate ich tatsächlich zu der bewährten Implementation von Apache Commons. Lieber das, als selbst etwas zu stricken.

Der Vollständigkeit halber: eine ähnliche Frage wurde ein paar Tage nach den Posts in diesem Thread bei stackoverflow gestellt. Die dortigen Antworten thematisieren zum einen die Performance-Unterschiede verschiedener Ansätze, zum anderen gibt es dort ein sehr schönes Beispiel, wie man eine eigene equals-Methode relativ einfach und schön zu lesen mit Hilfe von Google Guava implementieren kann.