Schönheitsfrage

[Der Wolf]

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

 

[Kai008]

Warum kein Array?

 

[Der Wolf]

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

 

[Chefkoch333]

Und warum ein Vector und keine List?

 

[Der Wolf]

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

 

[Chefkoch333]

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.

 

[Der Wolf]

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?

 

[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.

 

[zer0]

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?

 

[fassy]

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

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:

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:

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.