Softwareentwicklung in C++ - ASC

9.3 Abgeleitete Klassen 209
thode aus DisplayableObject und nicht, wie in unserer ersten Version aus
GameCard.
Die Implementation dieser Version (memory_game_card_v4.cpp) ist im
Prinzip vollkommen äquivalent zur vorherigen Implementation. Die einzige
Ausnahme ist das Inkludieren von memory_game_card_v4.h. Aus diesem
Grund erspare ich mir hier das Abdrucken des Source Codes. Auch das Testprogramm
(memory_game_card_v4_test.cpp) hat sich bis auf ein geändertes
Inkludieren nicht verändert. Ebenso wurde auch das dazugehörige Makefile
(MemoryGameCardTestV4Makefile) nur entsprechend adaptiert, um auch
displayable_object.cpp korrekt zu compilieren. Also möchte ich auch mit
diesen Files nicht sinnlos Seiten im Buch füllen.
Wie leicht einzusehen ist, ist Mehrfachvererbung eine sehr saubere
OO Möglichkeit, um verschiedene, voneinander unabhängige Eigenschaften
in verschiedenen Ableitungshierarchien getrennt voneinander zu modellieren.
Sollte eine Klasse mehrere Eigenschaften in sich vereinen, dann kann dies
durch multiple Inheritance sehr elegant gelöst werden. Eine solchermaßen
abgeleitete Klasse erbt alle Eigenschaften aller verschiedenen Basisklassen.
Jedoch kann es dabei auch zu ein paar technischen Problemen kommen,
wenn man nicht aufpasst! Wenden wir uns einmal einem leicht zu lösenden
Problem zu, bevor wir in Abschnitt 9.4 zu den harten Brocken kommen: Was
passiert, wenn beide Basisklassen ein- und dieselbe Methode implementieren?
Der Begriff ein- und dieselbe bezieht sich natürlich auf die vollständige Signatur,
also auch den Parametersatz. Würde der Parametersatz verschieden
sein, so würde sich ja einfach eine problemlos aufzulösende Overloading Situation
ergeben. Haben wir also wirklich komplette Gleichheit, welche der
Implementationen wird nun bei einem Aufruf vom Compiler eingesetzt? Wie
sich unschwer erraten lässt, keine der beiden! Der Compiler wird sich einfach
beschweren, dass er eine Ambiguität im Aufruf entdeckt hat und damit
das weitere Übersetzen verweigern. Das bedeutet also, dass die Entwickler
die Ambiguität per Hand auflösen müssen, um den Compiler zu beruhigen.
Wie dies passiert, sehen wir uns am besten an einem kleinen Beispiel an
(method_ambiguity_problem.cpp). Die erste Betrachtung gilt zwei Klassendeklarationen
in diesem Progrämmchen:
11 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
12 /∗
13 ∗ DisplayableObject
14 ∗
15 ∗ A simple d i s p l a y a b l e o bject
16 ∗
17 ∗/
18
19 class DisplayableObject
20 {
21 protected :
22 char ∗ s t r i n g r e p ;
23 DisplayableObject ( const char ∗ s t r i n g r e p ) ;
24 public :
25 ˜ DisplayableObject ( ) ;
26 const char ∗ getStringRep ( ) ;