Type safety von HashMaps

Hallo,

ich könnte mal einen Tipp gebrauchen. Ich habe folgendes Problem. Eine Methode gibt eine HashMap mit folgendem aussehen zurück:

Code:

---

HashMap<String, Object>

---

Diese HashMap soll verschiedene Objekte enthalten. Nun bringt mir Ecipse immer den Warnhinweis, daß die HashMap nicht Typsicher ist. Das weiß ich ja. In diesem Fall ist es ja gerade gewollt. Nun meine Frage : Gibt es programmiertechnisch eine Möglichkeit, die ich einfach nicht sehe, um eine HashMap so anzulegen, das die Warnmeldung nicht kommt?

Natürlich kann ich mit der Annotaion suppress warning den Warnhinweis ausschalten. Aber vieleicht ist der Code ja besser, wenn man es programmiertechnisch löst.

mfg
Anunnaki

Wenn die HashMap Objekte enthält, die als einzige gemeinsame Basis java.lang.Object haben, ist das meisten ein Hinweis auf eine Schwachstelle im Design.

Wie sieht denn dein Nutzen konkret aus, welche Objekttypen hast du denn so da drinnen?

Ciao,
_

Hallo anda_skoa,

zuerst einmal vielen Dank, für Deinen Beitrag. Nachfolgend ein etwas längerer Text. Aber wegen der zentralen Bedeutung der Typsicherheit in Java, wollte ich daß Problem etwas genauer schildern.

Ich habe mein Programm in Schichten aufgebaut. Einem DAO-Layer, für die Zugriffe auf die Datenbank, eine Logik-Schicht für die Businesslogic und einer Präsentationsschicht.
Der DAO-Layer arbeitet mit Hibernate.
Aus der Datenbank hole ich Objekte, die mit Hibernate gemapped wurden. Über die Businesslogik greife ich auf die Datenbank zu und erhalte Objekte verschiedener Klassen zurück. So bekomme ich zB ein Objekt der Klasse ClassA (objectA)zurück und eine List von Objekten von der Klasse ClassB (List<ClassB>listB). In der Businesslogic übergebe ich diese Objekte HashMaps.

Code:

---

HashMap<String,Object>map=new HashMap<String,Object>();
map.put(ClassA.getSimpleName(),objectA);
map.put(ClassB.getSimplenName(),listB);

---

Diese HashMaps übergebe ich nun der Präsentationsschicht, in der sie in DTO-Objekte, zur Weiterleitung an die GUI, umgewandelt werden.

Code:

---

ClassADTO objectADTO=ConverterClassA.buildDTO();
List<ClassBDTO>listDTO=ConverterClassB.buildDTOList();

---

Diese DTOs fasse ich dann in weitere DTOs zusammen; zB:

Code:

---

ContainerDTO containerDTO=new ContainerDTO();
containerDTO.setObjectA(objectADTO);
containerDTO.setListObjectB(listDTO);

---

und leite sie an die GUI weiter.
Durch die Verwendung von HashMaps in der Logikschicht erspare ich mir ähnliche Containerklassen, wie in der Präsentationsschicht. Durch diese Vorgehensweise kann die Applikation einfach von einer Swingoberfläche auf ein Webinterface umgestellt werden. Man muß lediglich die Convertierung ändern und ein geeignetes Format wählen.
So könnten die HashMaps aus der Logikschicht, in Servlets in JSON-Format gebracht werden und an einen Webclient übertragen werden. Auf doe Logikschicht und den DAOs hat dies keinen Einfluss.
Durch Einführung geeigneter Klassen, die die Ergebnisse der Logik zusammenfassen, wäre mein Problem gelöst. Diese wollte ich mir einfach sparen. Außerdem leisten die HashMaps genau das was ich brauche. Diese nun durch weitere Klassen zu ersetzen empfinde ich als unnötige Verkommplizierung des Programms. Und dies nur wegen der
Typsicherheit. In den meisten Fällen ist die Typsicherheit gut und wünschenswert. Manchmal aber auch eine Einschränkung der Möglichkeiten.

mfg
anunnaki

Eigentlich ist es ja unsinnig, die Typsicherheit einerseits erhalten zu wollen, andererseits aber aushebeln zu wollen. Andererseits denke ich mir, dass es so gehen müsste:

Man nehme ein Interface, z.B. IDAO. Das implementieren alle DAO-Klassen. Die Hashmap enthält dann <String, IDAO>. So ist immerhin ein Typ angegeben. Eine Einschränkung muss damit aber nicht verbunden sein.

Du hast ja recht. Prinzipiell finde ich die Typsicherheit auch gut. Aber wenn man sich sklavisch an alle irgendwie gearteten Vorgaben hält wird die Kreativität zu sehr eingeschränkt. Ein bisschen sollte man sich auch auf sein Können verlassen.
Trotzdem wäre hier eine Lösung schön, um die Warnhinweise weg zu bekommen ohne sie ganz abschalten zu müssen.
Auf jeden Fall werde ich Deine Vorschlag ausprobieren.

Zitat:

---

Zitat von anunnaki

Trotzdem wäre hier eine Lösung schön, um die Warnhinweise weg zu bekommen ohne sie ganz abschalten zu müssen.

---

Eine Lösung ist eben, wie vorgeschlagen, eine eigene Basis zu schaffen, anstatt auf die implizite Basis der Sprache zurpck zu greifen.
Hat den Zusatzvorteil, dass diese eigene Basis Methoden (bzw. im Falle eine Basisklasse auch Werte) zur Verfügung stehen kann, die im jeweiligen Anwendungsfall immer zur Verfügung stehen.

Ciao,
_