Softwareentwicklung in C++ - ASC

260 10. Memory – ein kleines Beispiel
Output Handling. Das Output Handling ist dafür verantwortlich, die Ausgabe
des gesamten Spielfeldes, respektive der einzelnen Karten auf ihm, zu
steuern und dafür zu sorgen, dass diese am Bildschirm erscheinen. Weil
auch dieses natürlich ein allgemeines Modul sein soll, wird hier das bereits
mehrfach besprochene Prinzip mittels einer abstrakten darstellbaren Klasse
Anwendung finden.
Da die Randbedingungen hierfür bereits mehrfach aus verschiedenen Gesichtspunkten
besprochen wurden, möchte ich den Lesern hier eine nochmalige
genaue Beschreibung ersparen.
Memory Spielfeld. Das Memory Spielfeld ist im Prinzip eine Matrix von
Einzelfeldern, wobei jedes dieser Einzelfelder genau eine Karte halten kann.
Im Prinzip gibt es hierfür eine besonders sinnvolle Konstruktion: Eine Matrix
ist im Prinzip nichts anderes als ein Vektor von Vektoren. Die dadurch entstehenden
Zellen halten jeweils eine Karte. Dazu lässt sich leicht ein besonders
sauberes Design mittels allgemeiner Vektoren und Spezialisierung derselben
auf bestimmte Daten beschreiben. Nur leider fehlen uns derzeit noch ein
paar wichtige Konstrukte, die eine elegante Umsetzung dieses Designs auf
C ++ Sprachebene ermöglichen. Aus diesem Grund bleiben wir zwar beim
allgemeinen Design, die Implementation desselben sollte aber bitte nicht als
Vorlage für ein professionelles Vektor-Design dienen.
Memory Karte. Zu den Aspekten des Designs einer Memory Karte möchte
ich mich hier auch nicht weiter auslassen, denn diese wurden bereits mehrfach
aus verschiedenen Blickwinkeln besprochen. Eine Wiederholung an dieser
Stelle wäre dementsprechend langweilig.
Commandline Handling. Das Commandline Handling bekommt die dem
Programm übergebenen Parameter überreicht und sorgt dafür, dass das entsprechende
Bootstrapping des Systems stattfindet. Im Bootstrapping werden
die entsprechenden notwendigen Instanzen der Klassen erzeugt und zwar in
der Form, wie sie den eingegebenen Parametern (Zeilen, Spalten) entspricht.
10.2 Das DDD
Viele Entwickler empfinden die Erstellung eines DDD (=Detailed Design Document)
als lästig und zeitraubend und deshalb wird diese Aufgabe oft nur
sehr halbherzig gemacht oder einfach vollständig übersprungen. In Summe
erspart man sich durch diese Herangehensweise aber keine Zeit, ganz im
Gegenteil! Durch das Fehlen des DDD fallen viele Probleme erst beim Implementieren
der Software auf und führen zu dementsprechend vielen kleineren
und größeren Änderungen derselben in dieser Phase. Das Schlimmste bei
diesen Änderungen ist, dass man es in Bezug auf die Schnittstellen mit einem
moving Target zu tun hat. Dadurch werden mit wachsender Größe der
Software die Fehler immer häufiger und schwerer zu lokalisieren, denn man