Softwareentwicklung in C++ - ASC

9.4 Weitere wichtige technische Aspekte 245
Nun ist es aber so, dass der übergebene Parameter event vom Typ Event
ist. Dort sind also die speziellen Methoden der davon abgeleiteten Klassen
KeyEvent und MouseEvent noch nicht bekannt, denn diese werden ja erst
in den abgeleiteten Klassen deklariert. Also können sie direkt auf event
natürlich auch nicht aufgerufen werden. Der Compiler würde ja z.B. bei
einem Aufruf
event.getKey();
gar nicht sehr freundlich reagieren und anmerken, dass man sich gefälligst einmal
die Deklaration der Klasse Event ansehen soll und nur Dinge verwenden
soll, die tatsächlich dort deklariert sind.
Jedoch ist aufgrund des Event-Typs, der in Zeile 135 abgefragt wird, sehr
wohl bekannt, dass es sich z.B. wirklich um einen KeyEvent handelt, auch
wenn dieser nur als Reference auf einen Event übergeben wurde. Also überzeugt
man den Compiler, dass man schon weiß, was man tut und setzt einen
expliziten Downcast auf KeyEvent ein, wie in den Zeilen 139–140 zu sehen ist.
Und genau hier sehen wir zum ersten Mal die wahre Natur von dynamic_cast:
Bei einem dynamic_cast wird zur Laufzeit eine Überprüfung vorgenommen,
ob diese Umwandlung überhaupt zulässig ist. Wenn ja, dann
wird die Umwandlung durchgeführt, wenn nein, dann endet das Programm
in einem Fehler – nun ja, muss nicht sein, wenn man weiß, wie man das Ende
des Programms verhindert. In Wahrheit wird eine Exception geworfen und
zwar eine bad_cast Exception. Wie man mit solchen Exceptions umgeht, ist
Thema von Kapitel 11. Was es ganz genau mit dieser besonderen Exception
auf sich hat, wird in Abschnitt 15.6 noch näher besprochen. Zurück zum
Thema: Nach einem zulässigen dynamic_cast, der nicht in einer Exception
endet, haben wir also sichergestellt, dass wir es tatsächlich mit einem Objekt
vom Typ KeyEvent zu tun haben und können damit auch getKey darauf
aufrufen.
Zu Beginn der Diskussion über Downcasts habe ich schon erwähnt, dass
man wirklich genau wissen muss, was man tut. Leider gibt es nicht allzu
wenige Entwickler, bei denen dieses Wissen eher rudimentär vorhanden ist,
die aber trotzdem Datentypen mittels Downcasts munter durch die Gegend
wandeln und so die schönsten Zeitbomben in ihre Software einbauen. In
altbekannter Manier möchte ich daher die häufigsten Fehlerquellen in der
Folge aufzeigen.
Vorsicht Falle: Downcasts sollten prinzipiell nur dann verwendet werden,
wenn sie unbedingt notwendig sind. Oft passiert es, dass bereits ein Fehldesign
vorliegt, das auf die Schnelle durch einen Downcast versteckt werden
kann (z.B. unnötig falscher Parameter in Methodenaufruf, etc.). Weil aber
Downcasts prinzipiell eine Gefahr darstellen, sollte man darüber nachdenken,
ob man vielleicht auch eine saubere Lösung ohne Downcasts finden kann. Das
bedeutet natürlich nicht, dass man Downcasts auf Kosten der Modularität,
Erweiterbarkeit und Allgemeinheit eines Programms vermeiden muss, aber