30.06.2013 Aufrufe

Softwareentwicklung in C++ - ASC

Softwareentwicklung in C++ - ASC

Softwareentwicklung in C++ - ASC

MEHR ANZEIGEN
WENIGER ANZEIGEN

Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.

YUMPU macht aus Druck-PDFs automatisch weboptimierte ePaper, die Google liebt.

164 8. Objektorientierung Allgeme<strong>in</strong><br />

e<strong>in</strong>en Kopf zu besitzen – ich habe bereits erwähnt, dass es nicht möglich<br />

ist, Eigenschaften e<strong>in</strong>fach wegzudef<strong>in</strong>ieren :-).<br />

• Neben vielen anderen Instanzen von Author gibt es auch irgendwo e<strong>in</strong>e<br />

Instanz, die Klaus Schmaranz entspricht, was sich durch den entsprechenden<br />

E<strong>in</strong>trag im name Member äußert. Auf dieser Instanz ruft man<br />

putHeadInPlace auf, was alle notwendigen Schritte setzt, um wieder Hoffnung<br />

zu schöpfen.<br />

Um dieses Kapitel nun endgültig abzurunden, möchte ich hier noch die zw<strong>in</strong>genden<br />

Grundregeln zur Verwendung der OO Mechanismen angeben:<br />

In unseren Beispielen haben wir gesehen, dass e<strong>in</strong>e spezielle Telefonklasse<br />

von e<strong>in</strong>er allgeme<strong>in</strong>en Klasse Telefon abgeleitet ist. Ebenso war e<strong>in</strong> Buchautor<br />

von e<strong>in</strong>er Klasse Mensch abgeleitet. Kl<strong>in</strong>gt auch logisch, denn das<br />

spezielle Telefon ist e<strong>in</strong> Telefon, nur mit Zusätzen und e<strong>in</strong> Autor ist auch<br />

sicher e<strong>in</strong> Mensch, nur mit zusätzlichen Eigenschaften. Das genau ist auch<br />

die semantische Bedeutung e<strong>in</strong>er Ableitung:<br />

E<strong>in</strong>e Ableitung e<strong>in</strong>er Klasse repräsentiert e<strong>in</strong>e IS-A Relation.<br />

Wir haben auch gesehen, dass der Kopf e<strong>in</strong>es Menschen <strong>in</strong> e<strong>in</strong>er Membervariable<br />

gespeichert wurde und das genau entspricht auch deren semantischer<br />

Bedeutung:<br />

E<strong>in</strong>e Membervariable repräsentiert e<strong>in</strong>e HAS-A Relation.<br />

Diese beiden Def<strong>in</strong>itionen gelten natürlich auch als Umkehrschluss:<br />

• Wenn etwas durch IS-A im Modell beschreibbar ist, dann ist e<strong>in</strong>e<br />

Ableitung das korrekte semantische Mittel zur Modellierung.<br />

• Wenn etwas durch HAS-A im Modell beschreibbar ist, dann ist<br />

e<strong>in</strong>e Membervariable das korrekte semantische Mittel zur Modellierung.<br />

• Zu diesen beiden Regeln gibt es ke<strong>in</strong>e e<strong>in</strong>zige Ausnahme! Jeder<br />

e<strong>in</strong>zelne Verstoß gegen e<strong>in</strong>e dieser beiden Regeln führt unweigerlich<br />

zur Katastrophe!!!<br />

Vorsicht Falle: Nicht nur von Neul<strong>in</strong>gen wird allzu oft der Fehler begangen,<br />

Ableitungen falsch e<strong>in</strong>zusetzen, nämlich <strong>in</strong> der Art, dass so etwas wie<br />

e<strong>in</strong>e IS-LIKE-A Relation modelliert wird. E<strong>in</strong> solches Konstrukt stellt e<strong>in</strong>en<br />

groben Designfehler dar, der sich im Lauf der Designphase und später bei<br />

der Implementierung bitter rächt.<br />

Nur um e<strong>in</strong> Beispiel zu nennen, das ich leider sogar <strong>in</strong> der Literatur als<br />

s<strong>in</strong>nvolle Ableitung erwähnt gefunden habe:<br />

• Es gibt e<strong>in</strong>e Klasse Array, die e<strong>in</strong>e saubere Implementation e<strong>in</strong>es dynamischen<br />

Arrays darstellt.<br />

• Es wird e<strong>in</strong>e Klasse Stack entworfen. Weil es gerade so gut dazupasst,<br />

dass man die Elemente des Stacks <strong>in</strong> e<strong>in</strong>em Array speichert, wird Stack<br />

von Array abgeleitet.

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

Erfolgreich gespeichert!

Leider ist etwas schief gelaufen!