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.

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

• Das Telefon <strong>in</strong>teragiert mit dem Ziffernblock. Für jede gedrückte Taste<br />

wird e<strong>in</strong> e<strong>in</strong>deutiger Impuls empfangen.<br />

• Das Telefon <strong>in</strong>teragiert mit der Gabel, die sich als e<strong>in</strong>facher e<strong>in</strong>/aus<br />

Schalter präsentiert.<br />

• Das Telefon <strong>in</strong>teragiert mit der Kl<strong>in</strong>gel. Es kann diese zum Läuten<br />

veranlassen.<br />

Vorsicht Falle: Ich kann es e<strong>in</strong>fach nicht lassen... Weil sich alles so banal<br />

liest und dazu verleitet, das Geschriebene als sowieso klar h<strong>in</strong>zunehmen,<br />

musste ich schon wieder e<strong>in</strong>en groben Designfehler e<strong>in</strong>bauen, der sich im<br />

Lauf e<strong>in</strong>er Entwicklung als echte Zeitbombe entpuppen kann.<br />

Im Beispiel wird davon ausgegangen, dass der Hörer nicht auf der Gabel<br />

liegen darf, wenn man mit dem Gegenüber spricht oder e<strong>in</strong>e Nummer wählen<br />

will. Das stimmt zwar, aber es ist nicht die ganze Wahrheit: In Wirklichkeit<br />

darf die Gabel nicht gedrückt se<strong>in</strong>, egal ob durch den Hörer, den F<strong>in</strong>ger<br />

des Telefonierenden, den Fuß des Telefonierenden, der gerade am Tisch liegt,<br />

oder sonst etwas. Modelliert man die Klasse so, dass nur der Hörer dafür<br />

verantwortlich zeichnet, dass die Gabel gedrückt ist, dann ist das e<strong>in</strong> glattes<br />

Fehldesign, das der Realität nicht entspricht. Wir wollen <strong>in</strong> unserem Modell<br />

aber die Realität nachbilden!<br />

Solcherart Fehler schleichen sich nur allzu leicht <strong>in</strong> e<strong>in</strong> Design e<strong>in</strong> und<br />

müssen später teuerst mit Programmänderungen oder irgendwelchen Workarounds<br />

wieder korrigiert werden. Zumeist aber werden bei solchen Korrekturen<br />

später nur Spezialfälle korrigiert, die gerade wichtig s<strong>in</strong>d. Damit ist zwar<br />

e<strong>in</strong> zu dieser Zeit wichtiger Fall abgedeckt, aber leider entfernt sich das Modell<br />

noch weiter von der Realität, was die nächsten gröberen Probleme dann<br />

gleich nach sich zieht. Aus diesem Grund kann ich nur e<strong>in</strong>en ganz wichtigen<br />

Ratschlag geben:<br />

Das erarbeitete Modell muss laufend mit der Realität verglichen werden,<br />

ob es nicht vielleicht von dieser abweicht. Jede Abweichung muss sofort korrigiert<br />

werden, denn Fehler im Programmdesign potenzieren sich im Lauf der<br />

Zeit. Vor allem verliert man die Vorteile des OO Ansatzes, denn man muss<br />

plötzlich beg<strong>in</strong>nen, von der Realität auf das Modell zu übersetzen, anstatt e<strong>in</strong>e<br />

direkte Abbildung zu haben!<br />

Nach Korrektur des Designfehlers lesen sich die entsprechenden Punkte<br />

folgendermaßen:<br />

Mögliche Interaktionen mit dem Telefon aus Benutzersicht:<br />

• Man kann e<strong>in</strong>e Nummer wählen, die man anrufen will. Das geschieht<br />

über den numerischen Ziffernblock. Damit das Telefon e<strong>in</strong>e Wahl auch<br />

akzeptiert, darf die Gabel nicht gedrückt se<strong>in</strong>.<br />

• Man kann e<strong>in</strong>en Anruf annehmen. Dazu hebt man den Hörer ab. Die<br />

Gabel darf nicht gedrückt se<strong>in</strong>.

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

Erfolgreich gespeichert!

Leider ist etwas schief gelaufen!