Wie mache ich die Variable xyz eindeutig/unique?

[uppss]

Hallo Jungs,

angenommen, ich habe eine einfache Klasse Person und dort einige Attribute wie:

public class Person {
    private String name;
    private String age;
}

Wie mache ich die Variable name eindeutig/unique?

 

[Robert Zenz]

Definiere "eindeutig".

 

[uppss]

unique

für die spätere Implementieruntg so etwa (schnell getippt):

public Person findPersonByName(String name) throws PersonException {
        Person p1 = new Person("a", 10); // a und b müssen eindeutig sein
        Person p2 = new Person("b", 11);
        Person p2 = new Person("b", 11); // sollte nicht gehen, oder soll ich zum Set greifen? Die Anforderung ist aber, dass name *eindeutig* sein muss :-)
       
        persons.add(p1);
        persons.add(p2);
   
        List<Person> persons = ArrayList<>();
   
        for (person : persons) {
            if (name.contains(name)) {
                return person
            } else {
                throw new PersonException();
            }
        }
    return null;
    }

 

[Robert Zenz]

Das kommt darauf an was genau du willst, willst du das ein Fehler geworfen wird, oder willst du die selbe Instanz wieder haben? So oder so musst du dir ein globales/statisches Set halten mit allen bereits vergebenen Namen in dem du dann nachschaust ob dieser Name bereits verwendet wurden.

Aber eigentlich habe ich mehr das Gefuehl dass du vielleicht die Anforderung falsch verstanden hast, das macht schon relativ wenig Sinn. Fuer gewoehnlich wuerde man bei so etwas eher ueber eine Fabrikmethode gehen und dann immer eine bereits erzeugte Instanz zurueckliefern wenn es fuer diese Werte bereits eine gibt.

 

[Neumi5694]

Du willst also, dass alle Personen einen eigenen Namen haben.
Speichere sie in einer Map ab: Map<String,Person>
Die Map bietet dir nun Möglichkeiten, zu prüfe, ob eine solche Person schon existiert (für das Werfen der Exception) oder auch praktische Methoden, Personen bei Bedarf neu anzulegen, z.B. putIfAbsent oder computeIfAbsent. Ich bevorzuge letztere, hier würde keine unnötige Person erzeugt, falls sie schon vorhanden ist. Außerdem wird immer der aktuelle Wert als Ergebnis geliefert, während putIfAbsent den vorher gespeicherten Wert liefert, also auch null.

Map (Java Platform SE 8 )

docs.oracle.com

 

[temi]

unique

für die spätere Implementieruntg so etwa (schnell getippt):

        Person p1 = new Person("a", 10); // a und b müssen eindeutig sein
        Person p2 = new Person("b", 11);
        Person p2 = new Person("b", 11); // sollte nicht gehen, oder soll ich zum Set greifen? Die Anforderung ist aber, dass name *eindeutig* sein muss :-)

Willst du bereits verhindern, dass die "doppelte" Person erzeugt werden kann?

Wie @Robert Zenz schon geschrieben hat, ist das vermutlich nicht gemeint. Eher, dass eine Liste von Personen keine Personen mit gleichem Namen enthält. Dazu hat @Neumi5694 schon was geschrieben. Es gibt natürlich noch mehr Möglichkeiten, z. B.

class Persons {
    private Set<String> names = new HashSet<>();
    private List<Person> persons = new ArrayList<>();
   
    public boolean add(Person person) {
        // Prüfe vor dem Hinzufügen der Person, ob der Name bereits vorhanden ist
    }
   
    // ...
}

Du kannst auch direkt ein Set<Person> verwenden, sofern dir die Methoden, die Set anbietet ausreichen. Aufpassen: In dem Fall muss die Klasse Person sowohl equals() als auch hashCode() überschreiben!

 

[temi]

Ein kleiner Hinweis (am Rande): Das funktioniert natürlich auch ohne das HashSet, indem du vor dem Hinzufügen prüfst, ob die Person schon in der Liste ist. Die HashSet.contains() Methode arbeitet allerdings in O(1), während für ArrayList.contains() O(n) gilt.

Im Gegenzug (für den Fall, dass du nur das Set verwenden würdest) sind die Zugriffsmethoden von Set (Iterator) eher langsam.

Die gezeigte Lösung kombiniert demnach das Beste aus Beiden, braucht dafür aber natürlich mehr Speicher.

Was "besser" ist, das hängt immer von den konkreten Anforderungen ab.

Falls ich mich in meiner Ausführung irre, dann bitte korrigieren.

 

[Oneixee5]

Ich könnte mir vorstellen, dass für eine Übung einfach nur Person#equals überschrieben werden soll.

 

[uppss]

vielen Dank, ich habe Person#equals überschrieben
Warum hashCode() überschreiben, habe ich noch nicht verstanden?

 

[Neumi5694]

vielen Dank, ich habe Person#equals überschrieben
Warum hashCode() überschreiben, habe ich noch nicht verstanden?

Wenn du eine Hashmap oder ein Hashset verwendest, wird anhand des Hashcodes entschieden, in welchem Subcontainer gesucht werden muss.
equals und in hashCode sollten deshalb immer die gleichen Felder berücksichtigen.

Edit: Ich denke, das ist vor allem eine Frage der Geschwindigkeit. Da ein überschriebenes equals nicht nur auf "this" prüft, sondern auch weitere Felder durchgeht, büßt eine Map etwas an Geschwindigkeit ein. Mit einer groben Gruppierung anhand des Hashcodes macht wieder etwas wett.
Ich bin mir jetzt auch gar nicht mal mehr so sicher, ob wirklich alle Felder aus Equals in hashCode berücksichtigt sein sollten, das hab ich nur mal als Empfehlung gelesen

 

[thecain]

Wichtig ist einfach:
Wenn equals true ergibt, müssen auch die HashCodes gleich sein. Deswegen macht es auch Sinn beim Überschreiben von equals, hashcode ebenfalls zu überschreiben.

Wenn equals ungleich ist, müssen die HashCodes nicht unterschielich sein. Theoretisch wäre also eine hashCode Methode die immer den selben Wert zurückgibt zulässig, wenn auch sehr sinnlos.

 

[KonradN]

Warum hashCode() überschreiben

Da ist die Antwort einfach: Wenn Du on anderen Klassen ableitest, musst der "Vertrag" eingehalten werden. Jedes abgeleitete Objekt muss sich so verhalten, wie das, wovon abgeleitet wurde (Siehe dazu Liskovs Substitution Principle).
Und der Vertrag bei hashcode und equals findet sich in Object:

Object (Java SE 17 & JDK 17)

declaration: module: java.base, package: java.lang, class: Object

docs.oracle.com

The general contract of hashCode is:

• Whenever it is invoked on the same object more than once during an execution of a Java application, the hashCode method must consistently return the same integer, provided no information used in equals comparisons on the object is modified. This integer need not remain consistent from one execution of an application to another execution of the same application.
• If two objects are equal according to the equals method, then calling the hashCode method on each of the two objects must produce the same integer result.
• It is not required that if two objects are unequal according to the equals method, then calling the hashCode method on each of the two objects must produce distinct integer results. However, the programmer should be aware that producing distinct integer results for unequal objects may improve the performance of hash tables.

 

[Neumi5694]

Der Vertrag wäre also auch mit einer konstanten Zahl erfüllt, wie thecain es oben beschrieben hat, was auch die default-Umsetzung ist (es sei denn, ich interpretiere einen der Punkte falsch)

 

[Neumi5694]

Ein kleiner Hinweis (am Rande): Das funktioniert natürlich auch ohne das HashSet, indem du vor dem Hinzufügen prüfst, ob die Person schon in der Liste ist. Die HashSet.contains() Methode arbeitet allerdings in O(1), während für ArrayList.contains() O(n) gilt.

Bei Hash-Umsetzungen hängt das stark davon ab, wie der Hashcode implementiert ist. Überschreibt man ihn nicht und es kommt immer die selbe Zahl, so landet alles im selben Container und das Ganze ist ähnlich schnell/langsam wie eine Liste. Nur wenn bekannt ist, wo das Element sich befindet, ohne irgendwas durchiterieren zu müssen, sind wie bei O(1).

Hier hat mal jemand was zu den Set und Zugriffszeiten geschrieben.

https://www.java-forum.org/thema/unterschied-arrays-listen-mengen.183754/

ps: Falls sich jemand Gedanken wegen der Berechnungszeit des Codes macht: Mehrere Berechnungsschritte hintereinanderkönnen moderne Prozessoren viel effizienter verarbeiten als Schleifen. Je nach Pipeline-Länge kann das alles in einem Zyklus (nicht zu verwechseln mit der Taktgeschwindigkeit) passieren, während eine Schleife mit nur einem Befehl ebenfalls jedes Mal auf das Ende des vollen Zyklus warten muss, selbst wenn es nur ein einfacher Befehl war. Es kann natürlich sein, dass diese Info nicht mehr akkurat ist (dass z.B. das Ergebnis aus einer Pipeline schon vor dem Ende erhalten werden kann), hab mich seit Ewigkeiten nicht mehr damit beschäftigt (Damals war Vektorprogrammierung der ganz große Wurf, danach kräht heute kein Hahn mehr).
Bitte in dem Fall korrigieren.

 

[KonradN]

was auch die default-Umsetzung ist (es sei denn, ich interpretiere einen der Punkte falsch)

Die default HashCode Methode gibt nicht einen konstanten Wert zurück. Was da beschrieben wurde ist, dass wenn auf einer konkreten Instanz mit einem Zustand mehrmals HashCode aufgerufen wird immer der gleiche Wert zurück gegeben wird.

Zwei unterschiedliche Instanzen oder wenn eine Instanz geändert wird, können unterschiedliche hashcode geben und die default Implementation gibt in der Regel für jede Instanz einen anderen Wert.

 

[thecain]

was auch die default-Umsetzung ist

Wenn ich mich jetzt nicht komplett täusche, ist der default hashcode oben nicht konstant

 

[temi]

was auch die default-Umsetzung ist

Der Text in der Dokumentation zu hashCode() geht noch weiter:

As much as is reasonably practical, the hashCode method defined by class Object does return distinct integers for distinct objects. (This is typically implemented by converting the internal address of the object into an integer, but this implementation technique is not required by the JavaTM programming language.)

 

[Neumi5694]

Wenn ich mich jetzt nicht komplett täusche, ist der default hashcode oben nicht konstant

Wurde mir im Forum hier so gesagt, nachdem ich was anderes behauptet hatte Ich sollte halt nicht alles glauben.
Der Quelltext hierzu ist eh nicht ersichtlich, eine native Methode wird aufgerufen (womit wir beim C-Teil der JRE angekommen wären).

 

[KonradN]

Wurde mir im Forum hier so gesagt

Wer hat das wo gesagt? Das würde mich schon interessieren. Zumal das ja sehr offensichtlich ist, denn der Hashcode wird ja auch in der default toString Methode verwendet und da sieht man ja immer wieder andere Hex-Zahlen.

 

[KonradN]

Also bezüglich equals / hashcode kenne ich nur einen Fall, wo man mit einem konstanten hashcode arbeiten könnte: Wenn man mit Entities z.B. mit Hibernate arbeitet, dann sollte man sich überlegen, wie man equals implementieren möchte.

Dazu gibt es dann z.B. folgenden Blog-Eintrag:

Ultimate Guide to Implementing equals() and hashCode() with Hibernate

Overriding the equals() and hashCode() methods of your entities is harder than it seems and often not necessary. Let me show you how and when to do it.

thorben-janssen.com

Die ganz kurze Zusammenfassung:

• Wann sind zwei Elemente gleich? Hier wäre die Idee, dass zwei Elemente, die gespeichert wurden, gleich sind, wenn die Id gleich ist. Wenn die Id null ist von einem oder mehrere Elemente, dann sind diese ungleich.
• Was nimmt man nun als hashcode? Da könnte man die id nutzen. Wenn die ID aber erst beim speichern erzeugt wird, dann könnte folgendes passieren;

1. Ein neues Element wird erzeugt. id ist null, hashcode ist dann halt, was man bei null id vorgesehen hat (z.B. 0)
2. Das neue Element nutze ich nun als key in einer HashMap.
3. Ich speichere das Element. Die id wird gesetzt, der Hashcode ist nun verändert.
4. Nun kann ich das Element nicht mehr in der Map finden, da der HashCode nun verändert ist.

==> Hier kann es also sinnvoll sein, einen fixen HashCode zu verwenden.

Ich nutze bei meinen Entities dennoch die Id als HashCode. Das setzt aber voraus, dass man eben eine Entity erst "speichert", ehe man diese in einer Struktur nutzt, die einen HashCode nutzt. Das ist eine Einschränkung, mit der ich sehr gut leben kann und die ich bisher nicht als Einschränkung empfunden habe.

 

[sastahai44]

Ein kleiner Hinweis (am Rande): Das funktioniert natürlich auch ohne das HashSet, indem du vor dem Hinzufügen prüfst, ob die Person schon in der Liste ist. Die HashSet.contains() Methode arbeitet allerdings in O(1), während für ArrayList.contains() O(n) gilt.