Fachkonzept - Typumwandlung

Ausgangsbeispiel

Hinweis: Im folgenden sind die Klassendiagramme Java-spezifisch und nicht in UML.

Um zu erklären was Typumwandlungen sind und wozu man diese benötigt, gehen wir von folgendem Beispiel aus:

Ein Shop kann also beliebige verkaufbare Objekte enthalten. Gültig wäre damit folgender Code:

Shop shop = new Shop();
shop.addArtikel(new Auto());
shop.addArtikel(new Kuchen());
shop.addArtikel(new Suppe());

Typprüfung

Möchte man den genauen Typ eines Objektes überprüfen, kann man das mit Hilfe des instanceof-Operators überprüfen:

Verkaufbar v = shop.getZufaelligenArtikel();
if(v instanceof Auto)
    System.out.println("Juhu, ich habe ein Auto");

Typumwandlung

Folgender Code lässt sich nicht compilieren, da der Rückgabetyp der Methode getZufaelligenArtikel() nicht passt:

Shop neuerShop = new Shop();
neuerShop.addArtikel(new Kuchen()); // einziger Artikel des Shops
Kuchen k = neuerShop.getZufaelligenArtikel();
k.backen();

Wenn man genau weiß, dass ein Objekt von einem bestimmten Typ ist, kann man mit einem Typecast den Typ explizit umwandeln:

Shop neuerShop = new Shop();
neuerShop.addArtikel(new Kuchen()); // einziger Artikel des Shops
Kuchen k = (Kuchen) neuerShop.getZufaelligenArtikel();
k.backen();

Das obige Programmfragment lässt sich compilieren, allerdings endet das Programm mit einer Fehlermeldung, falls der Typecast nicht erfolgreich ist.

Oft macht es Sinn Typüberprüfung und Typecast zu kombinieren:

Verkaufbar gewinn = shop.getZufaelligenArtikel();
System.out.println("Mein Gewinn ist so viel wert: " + v.getPreis());
if(gewinn instanceof Auto) {
    Auto a = (Auto) gewinn;
    System.out.println("Ich habe ein Auto gewonnen und das ist so schnell: ");
    System.out.println(a.getVMax());
}
// oder kürzer:
if(gewinn instanceof Nahrungsmittel) {
    System.out.println("Ich habe etwas zu Essen gewonnen. Der Nährwert beträgt: ");
    System.outprintln( ((Nahrungsmittel) gewinn).getNaehrwert() );
}

Schlechte Modellierung

Typecasts und die Anwendung des instanceof-Operators sind oft ein Zeichen für eine schlechte Modellierung. Manchmal lassen sie sich aber nicht vermeiden. Dennoch sollte man in solchen Fällen immer überlegen, ob man die Modellierung nicht verbessern kann.