Softwarearchitektur: Unterschied zwischen den Versionen
Aus Das Sopra Wiki
Thomas (Diskussion | Beiträge) Einführendes Zitat zur Definition |
Thomas (Diskussion | Beiträge) Beispiel (Schriftteil); will noch ein Bild dazu |
||
| Zeile 43: | Zeile 43: | ||
'''Vorsicht!''' Anforderungen ändern sich. Anfangs mögen z.B. wenige Einheitentypen geplant sein und entsprechend wird das irgendwie zurechtgehackt. Doch irgendwann wird doch beschlossen, dass man mehr möchte und dann werden Veränderungen schwierig. Ob und wo sich die Anforderungen verändern, lässt sich jedoch kaum vorhersehen. | '''Vorsicht!''' Anforderungen ändern sich. Anfangs mögen z.B. wenige Einheitentypen geplant sein und entsprechend wird das irgendwie zurechtgehackt. Doch irgendwann wird doch beschlossen, dass man mehr möchte und dann werden Veränderungen schwierig. Ob und wo sich die Anforderungen verändern, lässt sich jedoch kaum vorhersehen. | ||
== Beispiel == | |||
Eine erste Architektur entsteht meist ganz natürlich, wenn es darum geht Code zu strukturieren und Dopplungen zu vermeiden. Am Beispiel eines beliebigen Videospiels könnte das so aussehen, dass wir erst mal allen Code in unserer Game-Klasse gerade herunterschreiben. So würde für jeden Schritt/Tick Folgendes ausgeführt werden: | |||
* Eingabe wird erfasst (eine großes If- oder Switch-Anweisung) | |||
* Update der Spiellogik | |||
* Aktualisierung der Anzeige (Bilder werden ausgewählt und an die entsprechende Grafik-Schnittstelle weitergereicht) | |||
Nun bietet es sich an, diese verschiedenen Funktionalitäten in entsprechenden Klassen abzubilden, z.B. InputHandler, GameLogicUpdater, DisplayDrawer. Nun sind nur noch drei Zeilen Code in unserer Game-Klasse selbst nötig: | |||
* <code>inputHandler.handle(...)</code> | |||
* <code>gameLogicUpdater.update(...)</code> | |||
* <code>displayDrawer.draw(...)</code> | |||
Als nächstes stellen wir fest, dass in unserer GameLogicUpdater-Klasse viele verschiedene Einheiten bewegt werden: King, Queen, Knight... Alle davon haben eine Methode <code>move()</code>, die immer etwas anders funktioniert. Damit man die aber alle in eine Liste stecken kann, bietet sich hier die Verwendung eines Interfaces "Movable" an. Statt für jeden einzeln <code>move()</code> aufrufen zu müssen lässt sich das nun in einem einfachen Loop machen: | |||
<code>foreach (Movable movableUnit in units) { movableUnit.move(); }</code> | |||
Ebenso lässt sich zum Beispiel wieder der InputHandler unterteilen, in einen KeyboardInputHandler und einen MouseInputHandler. Im DisplayDrawer könnte zwischen Hintergrund, Vordergrund und GUI unterschieden werden und so weiter. Irgendeine Architektur kommt also in jedem Fall zustande. Die Qualität dieser Architektur kann schlussendlich nur dadurch bestimmt werden, wie leicht sich damit arbeiten lässt. | |||
== Referenzen == | == Referenzen == | ||
<references /> | <references /> | ||
