Softwareentwicklung in C++ - ASC

9.4 Weitere wichtige technische Aspekte 237
Designaspekte im Hinterkopf haben, die sich positiv auf ein klares Design
auswirken. Weiters werden solche Entwickler immer wieder überlegen, wie
man ein- und denselben Sachverhalt vielleicht auch anders und damit schlüssiger
und einfacher darstellen könnte. Auf diese Art finden sie das (hoffentlich)
sinnvollste aus mehreren verschiedenen möglichen Modellen für eine Problemstellung.
Unerfahrenere Entwickler (und auch schlimme Hacker) greifen gerne zum
ersten Modell, das ihnen logisch erscheint und dieses wird dann ohne Rücksicht
auf Verluste bis zum bitteren Ende durchgezogen. Dadurch werden allerdings
Programme zumeist unglaublich kompliziert und das Resultat lässt
jedes logische semantische Modell vermissen. Somit ist der böse Hack perfekt,
den sich niemand mehr zu ändern traut, denn jede Änderung an einem
Teil der Software wirkt sich mörderisch in anderen Teilen derselben aus.
Ich weiß schon, dass hier wieder einmal ein bisschen der Missionar in
puncto sauberes Design mit mir durchgegangen ist, aber die Gelegenheit war
einfach zu gut :-). Also zurück zum Thema: Nehmen wir einfach einmal
hin, dass die in Abbildung 9.2 skizzierte Klassenhierarchie für unser Problem
das schlüssigste Modell darstellt. Nach dem bisherigen Wissensstand lässt
es sich allerdings nicht in C ++ Code umsetzen, ohne dass sich der Compiler
fürchterlich beschwert und die Übersetzung verweigert! Den Grund für diese
Beschwerde finden wir im Speicherabbild, das der Compiler aus unseren
einzelnen Klassen in der Ableitungshierarchie erzeugt:
• Wir wissen, dass jede Klasse beim Ableiten alle Eigenschaften der Basis
vollständig erbt.
• Das bedeutet, dass beim Erzeugen der Instanz eines Objekts für alle einzelnen
Teil-Objekte, die aus den Klassen in der Hierarchie resultieren, Speicher
reserviert wird. Die Speicherbereiche bei Ableitungshierarchien kommen
hintereinander zu liegen.
• Nehmen wir nur die obersten beiden Ebenen der in Abbildung 9.2 skizzierten
Hierarchie, so ergibt sich folgendes Bild:
– Ein TextuallyDisplayable Objekt besteht aus zwei Teilobjekten. Es
wird also Speicher für Displayable und weiters Speicher für alles Weitere
reserviert, das TextuallyDisplayable noch an Members dazudefiniert.
– Für GraphicallyDisplayable und auch für Printable gilt dasselbe.
• Beziehen wir nun auch noch die dritte Ebene der Hierarchie in unsere Betrachtungen
mit ein, dann vervollständigt sich das Bild dahingehend, dass
für eine GameCard folgende Sub-Objekte ihren Speicherblock bekommen:
– TextuallyDisplayable
– GraphicallyDisplayable
– Printable
Und genau hier liegt das Problem: Zieht man in Betracht, dass jedes dieser
drei Sub-Objekte selbst wieder Displayable als Sub-Objekt besitzt, dann