Module

Der nächste Schritt besteht darin, die vorhandenen Anwendungsfälle zu studieren und in Module einzuordnen.
Diese Module werden sich später in Namespaces wiederfinden.

Um den positiven Effekt der Module zu erkennen, machen wir einen Zeitsprung in die Zukunft:

• Ohne Module könnte man später ein objektorientiertes Design entwickeln, bei der es eine Klasse Spielfeld gibt.
  Dieses Spielfeld bekäme eine Methode, um sich selbst auf der Festplatte zu Speichern und zu Laden.
  Führte man dann eine Analyse auf Single Responsibility Principle durch, würde man das Design verwerfen.
  Man hätte festgestellt, dass die eigentliche Aufgabe der Klasse Spielfeld darin besteht, die Daten rund ums Spielfeld zu halten. Diese auf der Festplatte zu Speichern und zu Laden ist eine zweite Aufgabe.
• Mit der vorher stattgefundenen Einteilung in Module, gäbe es ein Modul Speicherbank und beim ersten Design wird der Klasse Spielfeld erst gar nicht das Laden und Speichern zugeordnet, da sie sich in einem anderen Modul befindet.

Die Module von Japan War wurden wie folgt festgelegt:

• controller (Model-View-Controller Entwurfsmuster)
• game (Zugüberwachung, Regelüberwachung)
• player (menschlich, Computerspieler, entfernte Spieler (Multiplayer))
• randomizer (Würfel, Landverteilung)
• model (Model-View-Controller Entwurfsmuster)
• gameground (Spielfeld)
• storage (Kokus, Einheiten im Vorrat)
• units (Einheiten, Armeen, Sondereinheiten)
• network (Senden und Empfangen von Netzwerkdaten)
• storage (Speichern und Laden auf Festplatte)
• test (für Testprogrammcode)
• view (Model-View-Controller Entwurfsmuster)