Best Practice für implementierung von equals(...)

[jule37]

hallo liebe leute,

bin grad über einen fall gestolpert, wo meine schlampige implementierung von equals zu schwer debugbaren nullpointern geführt hat. da ich bisher nicht nennenswert viel mit hash containern gearbeitet hab, war es oft einfach nicht nötig equals zu implementieren, deshalb bin ich grad etwas verunsichert. folgendes:

meine jetzige equals implementierung funktioniert nun zwar wunderbar und nullpointer frei, allerdings habe ich irgendwie ein ungutes bauchgefühl dabei, einfach was code eleganz angeht. mich interessiert nun, was ihr von der equals implementierung haltet - ist das tatsächlich sauber so? weiss jemand, wie man es noch schöner machen kann bzw. kennt gängige best practice? der punkt ist, dass auf diese weise bei größeren klassen die equals methode unglaublich lang und unübersichtlich wird. irgendwie hab ich da grad ein brett vorm kopf.

jeder hinweis wäre toll, danke

hier der code

@Override
public boolean equals(Object o){
		
	if(!(o instanceof MyClass))
		return false;
	
	MyClass data = (MyClass)o;
	
	if(data.a == null && a != null)
		return false;
	else {
		if(!data.a.equals(a))
			return false;
	}
		
	if(data.b == null && b != null)
		return false;
	else {
		if(!data.b.equals(b))
			return false;
	}
	
	// Und so weiter für jedes relevante feld....
	
	return true;
}

 

[tuxedo]

Tipp: Eclipse kann dir eine passende Equals-Methode generieren ...

 

[SlaterB]

am Anfang auf == prüfen, für dasselbe Objekt muss jedes equals sowieso true ergeben,

-----

wenn data.a null ist, das eigene a auch, dann wird data.a.equals() ausgeführt -> NPE


überhaupt ist jede vermeidbare Code-Wiederholung schlecht, schreibe z.B.

if (!Helper.equal(a, data.a) {
  return false;
}
if (!Helper.equal(b, data.b) {
   return false;
}
... 

oder

return Helper.equal(a, data.a) && Helper.equal(b, data.b) && ..

in der statischen Methode equal kannst du dann ganz genau allgemeine Regel zu null & Co. aufstellen,
die Methode darf dann auch ruhig 10 Zeilen lang sein, steht ja nur einmal im gesamten Programm,

auch in der statischen Methode am Anfang auf == prüfen, noch vor null, falls für beide null Rückgabewert true erlaubt ist,

 

[jule37]

alles klar vielen dank euch beiden, das waren beides sehr hilfreiche hinweise mit denen ich jeweils etwas herumexperimentieren werde

 

[FArt]

Es fehlt noch was:
wichtig ist, dass die Überprüfung reflexiv, symmetrisch, transitiv und konsistent ist. Dazu kommt, dass man hashCode() passend überschreiben muss, wenn equals überschrieben wird.

Object (Java 2 Platform SE v1.4.2)

Eine gute IDE macht das alles zusammen, und zwar in der Regel richtig ;-)
Für die wenigen Ausnahmefälle, in denen die IDE das nicht sinnvoll übernehmen kann, muss man halt ein wenig nachdenken.

 

[Marco13]

Siehe AngelikaLanger.com - Implementing the equals() Method - Part 1 - Angelika Langer Training/Consulting und die Links am Ende des Seite...

 

[mvitz]

Ansonsten kann man auch in "Effective Java" von Joshua Bloch nachschauen. (kp ob es die Items Online gibt).

Für die Hilfsmethoden kann man z.B. auch commons-lang benutzen (Lang - Home) wobei hier die Frage ist, ob nur equals und hashcode (und ein paar toString) die mehr Library rechtfertigen.

 

[Marco13]

In den oben verlinkten Artikeln wird auch auf die Empfehlungen von Josh Bloch eingegangen - und gezeigt, warum dessen Empfehlungen in diesem speziellen Fall ausnahmsweise mal nicht so optimal sind...