Hey,

nur eine kurze Frage: Was ich theoretisch bräuchte ist eine Art Tabelle in der ich in jeder Zelle einen Vektor von Daten ablegen kann.
Ich würde ganz spontan auf so ein Konstrukt kommen ...

HashMap<String, HashMap<String, Vector<Float>>> ...

da ich aber auch gerne neues lerne und erst seit kurzem wieder mit Java programmiere wollte ich hier mal fragen, ob und wenn ja,
wie man sowas schöner hinbekommen kann.

Gruß
Der Wolf

Warum kein Array?

Weil die Werte nicht unbedingt hintereinander liegen sondern nach id's (vielleicht reicht auch statt string die hashmaps über int) sotiert sind.

Und warum ein Vector und keine List?

Tatsächlich ist es mittlerweile auch eine HashMap geworden da die Werte da auch je nach Art woher sie kommen aufgelistet werden müssen. :P

Also unschön finde ich es jetzt nicht unbedingt, ist zwar ein wenig verschachtelt, aber du es eben so brauchst...

Das einzige was ich noch bei der Definition ändern würde ist grundsätzlich (falls kein triftiger Grund dagengen spricht) die Interfaces zu verwenden. Also:
Map<String, Map<String, Vector<Float>>> ...

Die Methoden des Vectors sind syncronized. Deshalb sollte man sich fragen ob dies wirklich notwendig ist und ansonsten eine ArrayList bzw. LinkedList verwenden.

Naja ... wie gesagt, ein Vector ist es eh nicht mehr, sondern nun ebenfalls eine HashMap.
Was spricht eher für die Verwendung der Interfaces statt direkt HashMap zu schreiben?

Du solltest wenn möglich immer so abstract wie möglich deine Variablen und signaturen halten. Damit kann dein Code leichter wiederverwendet werden.
Das Interface definiert nur was eine Klasse und damit deine Variable kann. Die konkrete Implementierung interessiert bei der Deklarierung ja erstmal nicht sondern erst bei der Zuweisung.

Frameworks wie Spring setzen konsequent auf Interfaces, welche dann mittels Code injection mit einer konkreten Implementierung gefüllt werden.

Dein Codebeispiel funktioniert ohne frage, aber ich finde es schöner die Variablen immer möglichst abstrakt zu deklarieren.

Zitat von Chefkoch333

Du solltest wenn möglich immer so abstract wie möglich deine Variablen und signaturen halten. Damit kann dein Code leichter wiederverwendet werden.
Das Interface definiert nur was eine Klasse und damit deine Variable kann. Die konkrete Implementierung interessiert bei der Deklarierung ja erstmal nicht sondern erst bei der Zuweisung.

Frameworks wie Spring setzen konsequent auf Interfaces, welche dann mittels Code injection mit einer konkreten Implementierung gefüllt werden.

Dein Codebeispiel funktioniert ohne frage, aber ich finde es schöner die Variablen immer möglichst abstrakt zu deklarieren.

Was genau meinst du mit so abstrakt wie möglich?

Wenn du eine Methode in einer Klasse definierts wie z.B.

Code java:

1 2 3

public LinkedList<String> getNamesFromPersons(LinkedList<Person>){ [...] }

zwingst du den Nutzer der API dir eine LinkedList zu geben und auch eine LinkedList als Rückgabe zu unterstützen - obwohl er vielleicht bei sich lieber mit einer ArrayListe arbeitet.

Wenn du allerdings die Methode über das Interface definierst:

Code java:

1 2 3

public List<String> getNamesFromPersons(List<Person>){ [...] }

ist es für den Nutzer der API egal ob er eine ArrayList oder irgendeine Andere List Implementierung da reinstopft - du hast ja nur gesagt das du ein Objekt erwartest das das List Interface implementiert.

Wenn du jetzt intern den Code änderst musst der Aufrufer nicht seine Implementierung ändern weil du ja weiterhin das Interface unterstützt.

Also bei dir statt
HashMap<String, HashMap<String, Vector<Float>>> ... => Map<String, Map<String, Vector<Float>>> ...

allerdings bei sovielen Verschachtelungen würde ich lieber kleine Utilklassen einführen die die Zugriffe kapseln:

Code java:

1 2 3 4 5 6

Map<String, MyMap>;   class MyMap implements Map {    private Map<String, Vector<Float>;    [...] }

Neben besserer Lesbarkeit hast du dann auch hier den Vorteil - solltest du irgendwann mal den Vector gegen einen anderen Datentyp tauschen wollen - musst du nur die Utilklasse anfassen, sonst nichts ändern.

Ok, auf jedenfall vielen Dank für deinen Input. Das hat mir auf jedenfall schon weiter geholfen.

Hmm ... eventuell ist es doch sehr viel schöner, wenn ich mir aus den keys für die ersten beiden
HashMaps einen einzigen Key zusammen baue ... zum Beispiel durch key1 + "-" + key2 und
dann nur noch eine HashMap über eine HashMap habe. Das vereinfacht auf jedenfall die
Übersichtlichkeit und da ich garantieren kann, dass die Kombination der beiden Keys wie
oben beschrieben immer noch einzigartig ist, müsste das auch gut gehen.

Kann man machen. Finde ich aber nicht schön. Künstliche Keys durch die Verkettung von Strings zu erzeugen ist meiner Meinung nach nicht wirklich robust und auf lange Sicht hin nicht wartbar. Wenn es jetzt um ein kleines Project für das Studium o.Ä. geht ist das kein Problem.

Soviel kann ich verraten. Ein kleines Projekt ist es nicht. Da geht es um meine Dissertation. Aber trotzdem finde ich eine HashMap über eine HashMap über eine HashMap unschön und ziehe die Verkettung vor, da ich in diesem Fall garantieren kann,
das die einzel keys jeweils einzigartig sind und damit auch der Gesamtkey einzigartig sein müsste.

Dann würde ich wenigesten den Key als eigenes Objekt definieren, kann ja was ganz simples sein:

Code java:

1 2 3 4 5 6 7 8

public class HashKey{    String a;    String b;   public HashKey(String a, String b){   // [...]   }   // getter und ggfs setter }

Dann hast du halt einfach eine Map<HashKey,DataObject>

Das hat einfach den Vorteil das wenn du mal auf einen teil deines Keys zugreifen willst du nicht immer den Strign parsen und splitten musst. Oder denke z.B. du serializierst Keys raus und speicherst die irgendwo um sie bei einem späteren Programmstart wieder zu laden. Nach 3 Monaten stellst du fest das der Seperatorcharakter (falls es denn einen gibt) '|' ungümstig ist und du lieber '-' nehmen möchtest. Dann musst du deine rauserialisierten Keys migrieren - oder beide untersützen was die Sachen noch unübersichlicher macht. Wenn du jetzt sagts das du keinen Seperator hast - auch gut, dann verändert sich die Länge eines der Keyteile o.Ä.

Mit dem Object als Key kannst du all solche Fälle transparent handlen. Ich sag ja nicht das es nicht geht wie du es vorhast. Aber wenn du nach "Schönheit" fragst sage ich das es schöner ist sauber objektorientiert zu arbeiten. Das erhöht die Lesbarkeit und Wartbarkeit deines Programms.

Wenn irgendwann mal wer dein Programm übernimmt sieht er so sofot das der Key ein Object mit verschiedenen Teilen ist. Sonst sieht er nur einen langen String ud mus zusehen das er rausbekommt nach welchen Regel der zusammengesetzt ist usw.