Ende benötigen wir für die gesamte Anwendung noch eine EXE-Datei, mit der die Anwendung gestartet werden kann. Aufgabe dieses Hosts ist es, die benötigten Komponenten zu beschaffen und sie den Abhängigkeiten gemäß zu verbinden. Die Abhängigkeiten sind hier in Form von Konstruktorparametern modelliert. Folglich muss der Host die Komponenten in der richtigen Reihenfolge instanzieren, im Abhängigkeitsbaum von unten nach oben, von den Blattknoten zur Wurzel. Anschließend übergibt er die Kontrolle an das Portal. Für die vorliegende Anwendung, bestehend aus einer Handvoll Komponenten, ist diese Aufgabe trivial. Bei größeren Anwendungen kostet diese Handarbeit Zeit und sollte automatisiert werden. Die Grund-idee dabei ist: Man überlässt das Instanzieren der Komponenten einem DI-Container wie StructureMap [2] oder Castle Windsor [3]. Über ein eigenes Interface identifiziert man den Startpunkt der Anwendung, und los geht's. Ein solcher Host kann dann sogar generisch sein und in allen Anwendungen verwendet werden.
Denkbare Erweiterungen
Für wiederkehrende Aufgaben wäre es sinnvoll, das Schema der Datengenerierung speichern und laden zu können. Dies kann beispielsweise mit dem Lounge Repository [4] erfolgen. In der Architektur würde dafür ein weiterer Adapter ergänzt, mit dem ein Schema gespeichert und geladen werden kann. Natürlich müssten im Portal entsprechende Anpassungen vorgenommen werden, um entsprechende Menüfunktionen zu ergänzen.
DesWeiteren wäre es denkbar, die Generatoren zur Laufzeit dynamisch zu laden. Damit könnten Entwickler ihre eigenen Generatoren implementieren und verwenden, ohne dazu die gesamte Anwendung übersetzen zu müssen. Mithilfe eines DIContainers wie StructureMap oder des Managed Extensibility Framework MEF [5] sollte auch diese Erweiterung keine große Hürde darstellen.
Fazit
Bei dieser Aufgabe stellte sich heraus, dass die Benutzerschnittstelle einer Anwendung durchaus einige Zeit in Anspruch nehmen kann. Die eigentliche Funktionalität war dagegen schnell entworfen und implementiert. Das lag maßgeblich daran, dass ich mir im Vorfeld einige Gedanken über die Architektur gemacht hatte. Danach ging die testgetriebene Entwicklung flüssig von der Hand. [ml]
[1] Stefan Lieser, Meier, Müller, Schulze..., Testdaten automatisch generieren, dotnetpro 5/2010, Seite 108ff., www.dotnetpro.de/A1005dojo
[2] http://structuremap.sourceforge.net/
[3] http://www.castleproject.org/container/
[4] http://loungerepo.codeplex.com/ und Ralf Westphal, Verflixte Sucht, dotnetpro 1 1/2009, Seite 52f. www.dotnetpro.de/A0911Sandbox
| AUFGABE Daten umformen |
 |
Mogeln mit EVA
Eingabe, Verarbeitung, Ausgabe: Das EVA-Prinzip durchdringt die gesamte Softwareentwicklung. Eine Analyse der Datenstrukturen und die Verwendung der passenden Algorithmen spielen dabei eine herausragende Rolle. Stefan, fällt dir dazu eine Übung ein?
| Wer übt, gewinnt | |
 |
In jeder dotnetpro finden Sie eine Übungsaufgabe von Stefan Lieser, die in maximal drei Stunden zu lösen sein sollte.Wer die Zeit investiert, gewinnt in jedem Fall – wenn auch keine materiellen Dinge, so doch Erfahrung und Wissen. Es gilt :Falsche Lösungen gibt es nicht. Es gibt möglicherweise elegantere, kürzere oder schnellere Lösungen, aber keine falschen.Wichtig ist, dass Sie reflektieren, was Sie gemacht haben. Das können Sie, indem Sie Ihre Lösung mit der vergleichen, die Sie eine Ausgabe später in der dotnetpro finden.Übung macht den Meister. Also − los geht’s. Aber Sie wollten doch nicht etwa sofort Visual Studio starten... |
Wer kennt nicht Minesweeper, das beliebte Spiel, welches zum Lieferumfang von Windows gehört? Doch keine Sorge, es geht dieses Mal nicht wieder um eine aufwendige Benutzerschnittstelle, sondern um eine kleine Kommandozeilenanwendung. Die soll aus einer Eingabedatei eine Ausgabedatei erzeugen. Die Eingabedatei enthält die Beschreibung eines Minesweeper-Spielfeldes. Das Programm erzeugt als Ausgabedatei einen dazu passenden „Mogelzettel“. Der Aufruf erfolgt folgendermaßen:
mogelzettel spiel1.txt mogelzettel1.txt
Der Aufbau der Eingabedatei ist wie folgt: Die erste Zeile enthält die Anzahl der Zeilen und Spalten des Spielfeldes. Beide Zahlen sind durch ein Leerzeichen getrennt. Die nachfolgenden Zeilen enthalten dann jeweils die Konfiguration einer Zeile des Spielfeldes. Dabei sind freie Felder durch einen Punkt dargestellt, Felder mit einer Mine durch einen Stern. Hier ein Beispiel:
5 6
....*.
...*..
......
*....*
.*....
Für diese Eingabedatei soll eine Ausgabedatei erzeugt werden. Die Ausgabedatei gibt für jedes Feld die Anzahl der Minen in der unmittelbaren Nachbarschaft an. Jedes Feld hat maximal acht Nachbarn, folglich können maximal acht Minen in der Nachbarschaft eines Feldes vorkommen, am Rand des Spielfeldes sind es natürlich weniger. Felder, die selbst eine Mine enthalten, sollen mit der Ziffer 0 belegt sein, es sei denn, in der Nachbarschaft befinden sich Minen. Dann sollen diese ebenfalls gezählt werden.
Der Mogelzettel gibt also keine direkte Auskunft darüber, wo die Minen liegen, sondern nur über die Anzahl der Minen in den jeweils benachbarten Feldern.
Für das obige Beispiel soll folgende Ausgabedatei erzeugt werden:
001211
001121
111121
121010
211011
Sie dürfen davon ausgehen, dass die Eingabedatei im korrekten Format vorliegt. Geht in der Folge etwas schief, ist gegebenenfalls das Ergebnis inkorrekt, oder das Programm bricht sogar ab. Dies soll hier keine Rolle spielen.
Die Vorgehensweise bei der Lösung dieser Übung dürfte Lesern der vorhergehenden Übungen inzwischen geläufig sein. Zunächst sollten die Anforderungen geklärt werden. Dazu ist es sinnvoll, Beispiele aufzuschreiben. Eines habe ich Ihnen gegeben, vielleicht definieren Sie weitere, um beispielsweise Randfälle zu definieren. Da ich Ihnen als „Kunde“ nicht so ohne Weiteres für Rückfragen zur Verfügung stehe, treffen Sie gegebenenfalls selber sinnvolle Annahmen. Nach der Klärung der Anforderungen beginnt die Planung. Dieser Phase sollten Sie viel Aufmerksamkeit und Zeit schenken. Je intensiver
