Tonarten ändern, Werte verlieren

TL;DR: Wenn Sie veränderbare Objekte als Schlüssel in gehashten Sammlungen verwenden, führt eine Änderung dieser Objekte zum Bruch von Verträgen.

Probleme 😔

• Verlorene Werte
• Schwieriges Debuggen
• Der Verstoß gegen das Prinzip der geringsten Überraschung
• Unerwartetes Verhalten

Lösungen 😃

1. Verwenden Sie unveränderliche Objekte als Schlüssel.
2. Überschreiben Sie equals/hashCode gut.
3. Verwenden Sie abschließende Felder (sofern Ihre Sprache dies zulässt).
4. Neuaufbereitung nach Mutation (Dies ist eine übertriebene technische Lösung)

Kontext 💬

Wenn Sie veränderbare Objekte als Schlüssel in gehashten Sammlungen verwenden, kann das Ändern des Schlüssels nach dem Hinzufügen eines zugehörigen Objekts dazu führen, dass es nicht mehr abgerufen werden kann.

Dies geschieht, weil sich der Hashcode ändert und die Sammlung das Objekt nicht im richtigen Bucket finden kann.

Beispielcode 📖

Falsch ❌

 class MutableKey { int id; MutableKey(int newId) { this.id = newId; } @Override public int hashCode() { return this.id; } @Override public boolean equals(Object objectToCompare) { if (this == objectToCompare) return true; MutableKey that = (MutableKey) objectToCompare; return id == that.id; } } MutableKey key = new MutableKey(42); Map<MutableKey, String> map = new HashMap<>(); map.put(key, "Yes Album"); // The key mutates key.id = 90125; // Now you cannont retrieve the album System.out.println(map.get(key)); // Output: null

Richtig 👉

 class ImmutableKey { private final int id; ImmutableKey(int newId) { this.id = newId; } @Override public int hashCode() { return this.id; } @Override public boolean equals(Object objectToCompare) { if (this == objectToCompare) return true; ImmutableKey that = (ImmutableKey) objectToCompare; return id == that.id; } } ImmutableKey key = new ImmutableKey(42); Map<ImmutableKey, String> map = new HashMap<>(); map.put(key, "Yes Album"); System.out.println(map.get(key)); // Output: Yes Album

Erkennung 🔍

• Halbautomatisch

Sie können diesen Geruch erkennen, indem Sie prüfen, ob Sie veränderbare Objekte als Schlüssel in hashbasierten Sammlungen verwenden.

Automatisierte Tools wie Linter oder IDE-Inspektionen können veränderbare Schlüssel ebenfalls kennzeichnen.

Stichworte 🏷️

• Wandlungsfähigkeit

Niveau 🔋

• Dazwischenliegend

Warum die Bijektion wichtig ist 🗺️

Die Bijektion zwischen der realen Welt und Ihrem Programm ist wichtig, da sie sicherstellt, dass Ihre Objekte die Beziehungen, die sie darstellen sollen, genau widerspiegeln.

In der realen Welt sind Schlüssel oft unveränderlich (z. B. IDs, Namen).

Wenn Sie diese Schlüssel als veränderbare Objekte modellieren, unterbrechen Sie die Eins-zu-eins-Entsprechung zwischen der realen Welt und Ihrem Programm im MAPPER .

Wenn Sie diese Bijektion mithilfe veränderlicher Schlüssel unterbrechen, wird die Karte inkonsistent, was zu Abruffehlern und unerwartetem Verhalten führt.

KI-Generation 🤖

KI-Generatoren können diesen „Stank“ erzeugen, wenn sie veränderbare Objekte als Schlüssel generieren, ohne die Auswirkungen zu bedenken.

Dies ist selten der Fall, da KI-Generatoren unter primitiver Obsession leiden.

KI-Erkennung 🥃

KI-Generatoren können diesen Geruch mit Anweisungen erkennen, um die Verwendung veränderlicher Objekte in hashbasierten Sammlungen zu analysieren und potenzielle Probleme zu kennzeichnen.

Sie können die KI anweisen, nach Klassen ohne endgültige Felder oder Methoden zu suchen, die den Status des Objekts nach der Erstellung ändern.

Probieren Sie sie aus! 🛠

Denken Sie daran: KI-Assistenten machen viele Fehler

Fazit 🏁

Wenn Sie veränderbare Objekte als Schlüssel verwenden, besteht die Gefahr, dass der Vertrag zwischen dem Status des Schlüssels und dem Hashcode gebrochen wird.

Verwenden Sie unveränderliche Objekte, um dieses Problem zu vermeiden.

Beziehungen 👩‍❤️‍💋‍👨

https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-xxxiv

https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-xxv

https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-xxiv

https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-xxxvi

https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-xviii

https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-xxvi

https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-xlii

Weitere Informationen 📕

Haftungsausschluss 📘

Code Smells ist meine Meinung .

Credits 🙏

Foto von Kathyryn Tripp auf Unsplash

Die wichtigste Eigenschaft eines Programms ist, ob es die Absicht seines Benutzers erfüllt.

Auto Hoare

Dieser Artikel ist Teil der CodeSmell-Reihe.