Map.Entry vs. eigene Container-Klasse

oraclin25

Erfahrenes Mitglied
Hallo zusammen,

ich hatte gestern eine kleine verbale Auseinandersetzung mit meinem Chef-Entwickler:
Wir brauchen so etwas:

Integer-Key String-Value
1 eins
2 zwei
1 EINS

Dafür ist wohl ein normales HashMap nicht geeignet, da der Wert vom Key 1 überschrieben würde.

Deshalb habe ich Map.Entry genommen. Das ganze verpacke ich in eine Liste, so dass ich sogar drüber iterieren kann:

Code:
List<Map.Entry<Integer, String>> pairList = new ArrayList<Map.Entry<Integer, String>>();
Map.Entry<Integer, String> pair1 = new AbstractMap.SimpleEntry<>(1,"eins");
Map.Entry<Integer, String> pair2 = new AbstractMap.SimpleEntry<>(2,"zwei");
Map.Entry<Integer, String> pair3 = new AbstractMap.SimpleEntry<>(1,"Eins");

Beim Code-Review fings an, er hätte Map.Entry nie gesehen, geschweige denn genutzt. Ich kanns ehrlich gesagt nachvollziehen, ich selber habe davor Map.Entry auch noch nie gesehen. Er fragte mich, warum ich nicht einfach eine eigene Container-Klasse baue. Ich meinte darauf hin, ich wollte darauf verzichten, dass für so eine "Kleinigkeit" eine Container-Klasse gebaut wird.

Was meint Ihr? Ist ein Argument wie "der Code ist schwer zu lesen" gerechtfertigt? Zugegebenermaßen, im Zusammenhang mit der fachlichen Anforderung, die so mit diesem Code programmiert ist, ist der Code nicht vom ersten Blick zu verstehen. Aber nochmal, ist das ein Grund, den Code als schlecht zu bewerten?

Vielen Dank für Eure Kommentare.

Viele Grüße aus Rheinland,
Eure Ratna
 

Cromon

Erfahrenes Mitglied
Hallo Ratna

Zuerst: Ich stimme mit deinem Chef-Entwickler überein, diesen Code würde ich nicht verwenden. Map.Entry steht für einen Eintrag einer Map, also soll es auch ein Eintrag einer Map sein.

Anschliessend: Solche scheinbar "unlösbare" Probleme mit "Lesbarkeit vs. Entwicklungszeit" entstehen in der Regel durch schlechtes Design. So auch hier: Warum hat ein Key mehrere Values? Lässt sich das nicht vermeiden? Das wäre wohl der mit Abstand kürzeste Weg. Entweder indem Value nicht ein String sondern eine Collection von Strings ist oder indem du eine Multimap verwendest oder aber die gleichen Werte auch nur einmal in der Collection haben musst.

Was mir jedoch an deinem Chef-Entwickler gar nicht gefällt ist der Vorschlag einen eigenen Container zu entwickeln. In der heutigen Zeit muss man solche Basissachen eigentlich so gut wie nie selber implementieren, siehe z.B. org.apache.commons.collections.MultiHashMap.

Und zu der/den letzten Frage(n): Lesbarkeit von Code ist eines der wichtigsten Kriterien, da es in der Regel alle anderen direkt beeinflusst. Code, der nicht lesbar ist ist schlecht wartbar. Code, der nicht lesbar ist ist schlecht erweiterbar, usw.

Viele Grüsse
Cromon
 

ComFreek

Mod | @comfreek
Moderator
Ich stimme Cromon zu.
Zuerst: Ich stimme mit deinem Chef-Entwickler überein, diesen Code würde ich nicht verwenden. Map.Entry steht für einen Eintrag einer Map, also soll es auch ein Eintrag einer Map sein.
Wenn du wirklich bei deinem Code bleiben möchtest, dann könntest du wenigstens das allgemeinere java.util.Pair anstatt Map.Entry nutzen. Es ist insofern allgemeiner, als dass es nicht zu Map gehört, andererseits besitzt es "first" und "second" Attribute anstatt der aussagekräftigeren key und value Attribute eines Map-Eintrags.