Das sollten eigentlich auch alle selbst geschriebenen Klassen haben :wink:Tobias hat gesagt.:
bis man dann monate spaeter auf die idee kommt mal seine Objekte in Sets oder Maps zu stecken und dann sich Fehler nicht erklaeren kann...Gast hat gesagt.:
deathbyaclown hat gesagt.:
vll versteh ich dich falsch, aber zu sagen, nix zu ueberschreiben und dann klappts ohne probleme stimmt nichtAnonymous hat gesagt.:
public class TestClass {
public static void main( String[] args ) throws IOException {
Map<Te, String> tt = new HashMap<Te, String> ();
tt.put(new Te("123"), "45");
System.out.println(tt.containsKey(new Te("123")));
}
}
class Te {
private String t;
public Te(String t) {
this.t = t;
}
}
deathbyaclown hat gesagt.:
Oh Mann - jatzt hast Du mich aber in Grund und Boden argumentiert. :?Leroy42 hat gesagt.:
API hat gesagt.:
kleiner_held hat gesagt.:
kleiner_held hat gesagt.:
) zurückgeht und deshalbEquals und hashCode haben doch vorgegebene Aufgaben die sie erledigen sollen.kleiner_held hat gesagt.:
kleiner_held hat gesagt.:
Jup, ich beschränke mich bei equals() auch auf Klassen, bei denen eine logische Gleichheit Sinn macht, also im Bereich des Models.byto hat gesagt.:Einen guten Punkt sprichst Du da an. Ich schränke meine Aussage von oben mal auf Objekte des Datenmodells ein. Ich wäre auch nie auf die Idee gekommen, die equals() in einer GUI Klassen zu überschreiben.
Eine richtige Implementation von equals und hashCode setzt doch gerade vorraus, dass wenn equals stimmt hashCode eben auch die selben Werte liefert.SlaterB hat gesagt.:wenn es keine argen Probleme geben soll
(z.B. unter anderem Hashcode abgespeichert als jetzt aktuell/
equals stimmt, aber Hashcode nicht gleich)
dann gibt es nur eine sichere Methode: nämlich genau die Operationen NICHT zu überschreiben
)Java Doc zu equals hat gesagt.:
Java Doc zu Set hat gesagt.:
Das Problem liegt aber doch ganz woanderst.kleiner_held hat gesagt.:In dem Zusammenhang bin ich halt eher fuer eine sehr restriktive Handhabung von equals (also Konsistenz auch trotzt der Aenderung von mutable Properties) - auch weil ich schon mal viel Schweiss gelassen habe, um eine derartige Fehlerquelle zu finden. Solche Erfahrungen prägen halt
public class HashMapSample
{
public static void main(String[] args)
{
Set<Entry> set1 = new HashSet<Entry> ();
Set<Entry> set2 = new HashSet<Entry> ();
Entry entry1 = new Entry("Test");
Entry entry2 = new Entry("Test");
System.out.println("Result of add entry1 to set1 = " + set1.add(entry1));
System.out.println("Result of add entry1 to set1 = " + set1.add(entry1));
System.out.println("Result of add entry2 to set1 = " + set1.add(entry2));
for (Entry entry : set1)
{
System.out.println("Set1 contains:"+entry.toString());
}
System.out.println("Result of add entry1 to set2 = " + set2.add(entry1));
entry1.setContent("Toast");
System.out.println("Result of add entry1 to set2 = " + set2.add(entry1));
for (Entry entry : set2)
{
System.out.println("Set2 contains:"+entry.toString());
}
}
private static class Entry
{
private String content;
public Entry(String content)
{
this.content = content;
}
public String getContent()
{
return content;
}
public void setContent(String content)
{
this.content = content;
}
public boolean equals(Object obj)
{
if (! (obj instanceof Entry))
{
return false;
}
return content.equals(((Entry) obj).content);
}
public int hashCode()
{
return content.hashCode();
}
public String toString()
{
return content;
}
}
}Wie gesagt, da stimme ich dir bedenkenlos zu. Wenn ich eine Art ID hab ist das gut.kleiner_held hat gesagt.:
kleiner_held hat gesagt.:
Warum sollte das hier schöner sein?
Es komtm doch drauf an wie man equals überschreibt und nicht ob man dies tut.kleiner_held hat gesagt.:
- Jede Instanz einer Klasse ist naturgemäss einzigartig.
Das gilt allgemein für Aktionsklassen, zum Beispiel für die Klasse "Thread".
- Die "logische Gleichheit" einer Klasse interessiert keinen.
Beispiel: java.util.Random hätte "equals" überschreiben können, damit man schauen kann,
ob zwei Random Instanzen die gleiche Folge von Zufallszahlen ergeben.
Das wurde aber nicht gemacht, weil man davon ausgeht, daß keiner das will.
- Eine Superklasse hat schon "equals" überschrieben und das ererbte Verhalten genügt dieser Klasse.
- Die Klasse ist "private" oder "package-private" und du bist sicher,
daß "equals" niemals aufgerufen wird. Man könnte in dem Fall "equals" aber auch so überschreiben,
daß sie eine "UnsupportedOperationException" wirft.
