> dann wäre doch hashcode nur gleich wenn auch vergleich mit == true wäre.
weitgehend richtig, siehe aber aber auch b) weiter unten
> aber der is doch auch gleich wenn nur der inhalt gleich is...
falsch oder Gegenbeispiel nennen
dass es für bestimmte Objekte wie String anders aussieht,
ist unbestritten
---------
> habs jetzt so gemacht:
> public int hashCode() {
> return path.hashCode()+type;
> }
ohne zu wissen was path und type ist, kann man dazu kaum was sagen,
sieht aber gut aus,
die equals-Operation halbwegs ok, aber gefährlich, 3 Hinweise:
a) funktioniert nur dann einigermaßen, wenn hashCode alle enthaltenen Felder berücksichtigt,
übrigens könnte die hashCode()-Berechnung aufwändiger als andere Überprüfungen sein,
bei zwei String kann man anhand der Länge die meisten Unterschiede sofort erkennen, da muss nicht unbedingt der hasCode über jeden Buchstaben einzelnd errechnet werden
b) du hast noch die Gefahr, dass dein Hashcode zufällig dem eines anderen Objektes entspricht, welches nicht equal ist,
es gibt nur Integer.MAX_VALUE Hashcodes,
aber bestimmt viel mehr Möglichkeiten, etwa Strings der Länge 10 oder höher bei den Unmengen an verschiedenen Buchstaben,
aus equal folgt zwingend gleicher Hashcode, aber gleicher Hashcode heißt normalerweise nicht immer equal,
ist zwar wahrscheinlich und daher so nützlich für das HashSet,
aber nicht zwingend
c) auch ein Objekt einer ganz anderen Klasse könnte den gleichen Hashcode haben
-----------
> oder soll ich ne andere collection verwenden?
für TreeSet musst du glaube ich Comparable implementieren,
aber schaue dir doch mal alle verfügbaren Sets an,
nur mit equals wirds knapp,
dann kannst du aber immer noch eine normale Liste nehmen und vor jedem Einfügen contains() prüfen, das läuft die ganze Liste durch und verwendet nur equals()