30.06.2013 Aufrufe

Softwareentwicklung in C++ - ASC

Softwareentwicklung in C++ - ASC

Softwareentwicklung in C++ - ASC

MEHR ANZEIGEN
WENIGER ANZEIGEN

Erfolgreiche ePaper selbst erstellen

Machen Sie aus Ihren PDF Publikationen ein blätterbares Flipbook mit unserer einzigartigen Google optimierten e-Paper Software.

202 9. Klassen <strong>in</strong> <strong>C++</strong><br />

die Rückseite der Karte <strong>in</strong> den entsprechenden Members <strong>in</strong> den Zeilen 19–20.<br />

Damit aber nicht genug: Unsere besondere Karte implementiert auch e<strong>in</strong>en<br />

besonderen Konstruktor, der andere Parameter nimmt als der, der von der<br />

Basis vorgegeben ist. In unserem Fall wollen wir ja sowohl die Darstellung der<br />

Vorder- als auch die Rückseite der Karte von außen vorgegeben bekommen.<br />

Weil das noch nicht alles war, was wir erreichen wollen, def<strong>in</strong>ieren wir <strong>in</strong><br />

der abgeleiteten Klasse noch e<strong>in</strong>e Methode getDisplayRep. Diese Deklaration<br />

allerd<strong>in</strong>gs bewirkt etwas, was wir bisher noch nicht kennen gelernt haben:<br />

Wenn man sich die Deklaration von getDisplayRep <strong>in</strong> MemoryGameCard ansieht<br />

und mit der Deklaration <strong>in</strong> GameCard vergleicht, dann fällt auf, dass<br />

diese beiden Deklarationen tatsächlich vollkommen identisch s<strong>in</strong>d! Nun haben<br />

wir aber beim Overload<strong>in</strong>g gesagt, dass so etwas gar nicht se<strong>in</strong> darf, weil<br />

der Compiler dann nicht ause<strong>in</strong>ander halten kann, welche Implementation er<br />

nun e<strong>in</strong>setzen soll!<br />

Um die Verwirrung perfekt zu machen: Im Falle von Ableitungen darf<br />

es doch se<strong>in</strong> und es nennt sich Overrid<strong>in</strong>g. Dies bedeutet, dass e<strong>in</strong>e genau<br />

äquivalente Deklaration (und natürlich auch Def<strong>in</strong>ition) <strong>in</strong> e<strong>in</strong>er abgeleiteten<br />

Klasse die ursprüngliche Def<strong>in</strong>ition, die der Basisklasse zugrunde lag,<br />

versteckt. Ruft man also auf der Klasse MemoryGameCard die Methode<br />

getDisplayRep auf, so wird die Def<strong>in</strong>ition aus der abgeleiteten Klasse genommen<br />

und nicht die aus der Basisklasse GameCard, da diese durch die<br />

Neudeklaration und Def<strong>in</strong>ition zugedeckt wurde. Um e<strong>in</strong> Overrid<strong>in</strong>g zu erreichen,<br />

muss die Deklaration genau gleich aussehen, wie die ursprüngliche,<br />

ansonsten kommt es nur zu e<strong>in</strong>em Overload<strong>in</strong>g, es würden also beide Methoden<br />

friedlich nebene<strong>in</strong>ander existieren.<br />

Dasselbe, was für Methoden gilt, gilt natürlich auch für Membervariablen.<br />

Auch hier kann man e<strong>in</strong>e Variable <strong>in</strong> e<strong>in</strong>er abgeleiteten Klasse def<strong>in</strong>ieren, die<br />

denselben Namen hat wie die <strong>in</strong> e<strong>in</strong>er ihrer Basisklassen (direkt oder weiter<br />

oben <strong>in</strong> der Ableitungshierarchie). Damit wird, wie zu erwarten, die Variable<br />

der Basisklasse versteckt, existiert aber parallel zur hier def<strong>in</strong>ierten.<br />

Vorsicht Falle: In der Literatur werden leider nur allzu oft die Begriffe<br />

Overload<strong>in</strong>g und Overrid<strong>in</strong>g verwechselt oder sogar austauschbar verwendet.<br />

Dies ist aber absolut falsch und sorgt leider immer wieder für große<br />

Verwirrung und Missverständnisse.<br />

Overload<strong>in</strong>g bezeichnet das gleichzeitige Existieren mehrerer Funktionen<br />

oder Methoden nebene<strong>in</strong>ander, die verschiedene Parametersätze haben.<br />

Overrid<strong>in</strong>g bezeichnet das Verstecken e<strong>in</strong>er Methode bzw. Variable <strong>in</strong><br />

e<strong>in</strong>er Ableitungshierarchie durch e<strong>in</strong>e Methode bzw. Variable mit genau derselben<br />

Deklaration. Das bedeutet, dass e<strong>in</strong> Overrid<strong>in</strong>g E<strong>in</strong>fluss auf den Scope<br />

von Methoden und Variablen nimmt. Wie wir später noch sehen werden, ist<br />

trotz Overrid<strong>in</strong>g e<strong>in</strong> Zugriff auf die dadurch versteckten Def<strong>in</strong>itionen mittels<br />

Scope Operator möglich.

Hurra! Ihre Datei wurde hochgeladen und ist bereit für die Veröffentlichung.

Erfolgreich gespeichert!

Leider ist etwas schief gelaufen!