Vorwort
Das ist das Triumvirat der modernen Softwarearchitektur. Einige werden sich jetzt fragen, was ich ihnen eigentlich erzählen will? Nun dann will ich mal ganz vorne anfangen. Zuerst einmal ein kurze Einführung. Ich werde ab September wieder in der Desktop basierten Softwareentwicklung tätig sein. Das gute daran ist, es wird eine Neuentwicklung werden. Und da wittere ich jetzt die Gelegenheit Architekturkonzepte aufzugreifen, die sich schon länger entwickelt haben und immer mehr in Mode kommen.
UnitTesting
Bereits vor vielen Jahren hat Kent Beck mit Extreme Programming den Meilenstein für eine heranwachsende Softwaregeneration gelegt. Er ist - so würde ich es bezeichnen - der Urvater der modernen Testframeworks. Er hat SUnit für Smalltak entwickelt und dann später mit Erich Gamma das ganze nach Java als JUnit portiert. Wer gut aufgepasst hat wird sich jetzt vielleicht fragen, ob das was mit NUnit zu tun hat. Und wie! Schlussendlich ist diese ganz N-Produkt-Sache an Java angelehnt. Viele Gute Frameworks haben den Transfer aus der Javawelt in das .NET Zeitalter gut überstanden und erleben hier einen großen Anklang und Aufschwung.
Nun zurück zu meiner Überschrift. Im laufe der Jahre sind immer mehr Probleme in der objektorientierten Entwicklung entstanden. Spaghetti Code ist den tief verschachtelten Klassenhierarchien gewichen und hat so den Weg zu der gleichen Komplexität geebnet. Nun haben sich Architekten dafür aber wieder etwas einfallen lassen.
Da UnitTesting schon zum guten Ton gehört und es sich aus neu entstehenden Projekten eigentlich nicht mehr wegdenken lässt will ich hier auch weitere Schwerpunkte legen und aufzeigen. Was macht das Testen aber schwierig? Nun ja, wie bekomme ich Abhängigkeiten innerhalb von Klassen geregelt, die nach aussen hin nicht sichtbar sind, also private oder protected? Über das .NET Framework können diese Beschränkungen umgangen werden.
Type Mocking
So kommen wir doch nun aber mal einen Schritt weiter. Ich will Klassen testen, die wiederum von anderen abhängig ist. Schon früher war klar: Es müssen Verträge geschaffen werden und diese nennen sich eben einmal Schnittstellen (Interfaces). Hier kommt Type Mocking ins Spiel. Was ist das, ein Mock (Attrappe)? Diese Technik dient dazu zu einem vorgebenen Interface ein konkrete Implementierung zu erstellen und dabei alle notwendigen Abhängigkeiten von aussen zu injizieren.
Bei UnitTests kann das verwendet werden um einzelne Komponenten unabhängig von ihrem Gesamtsystem, indem sie Leben zu testen. Auch Komponenten können ja ihrerseits wieder Abhängigkeiten haben. Dies kann durch Type Mocking in Einheitentests eliminiert werden, indem wir Komponente A sagen, wie B aussieht, und wie sie sich verhält. Dabei genügt es vollkommen nur ein Interface davon zu besitzen. Wir bauen uns zur Laufzeit, on the fly, das benötigte Objekt B zusammen und jubeln es Komponente A unter. So bekommen wir ein Funktionierendes System. Wir können also unsere Tests abgeschlossen als Sandbox laufen lassen. Das ist ein Technik, die sehr gut funktioniert und aus dem Unittesting nicht mehr wegzudenken ist.
Dependency Injection
Meine Damen und Herren ich darf ihnen nun Dependency Injection oder kurz DI präsentieren. Es ist eine Spezielle Implementierung des Inversion of Control (IoC) Patterns. Dabei leistet DI mehr als sein Muster IoC, das mittlerweile nur einen Teil davon abbildet. Mit DI schaffen wir, was die Objektorientierung in jahrelanger Arbeit angerichtet hat: Wir lösen die starke Kopplung und Verdrahtung von Abhängigkeiten und schaffen eine überschaubare und wartbare Komplexität.
Dazu gibt es einen Container, bei dem alle Interfaces und Objekte registriert werden. Der Container kann dabei als Factory dienen und als alleswissender Dispatcher. Wird ein Objekt, oder Service benötigt, so stellen wir nur eine Anfrage an den Container und er liefert uns das passende Objekt zurück.
Zu schön um wahr zu sein? Nein, schon seit langem lebende Praxis. Diese etwas längere Einführung sollte nur ein kurzer Artikel sein um euch das ganze schmackhaft zu machen. Ich werde nun im folgenden ein paar Frameworks aufzählen, so dass jeder, der sich schon einmal voraus informieren will den nötigen Startpunkt hat.
Frameworks und Schlagworte
Dependency Injection (und mehr)
UnitTesting
Type Mocking
Schlusswort
Das sollte für den Anfang erst einmal reichen. Ich beschäftige mich in der Theorie mit diesen Themen schon seit ca. zwei Jahren immer mal wieder. Natürlich immer wieder jeweils aufbauend zum nächsten kommenden Thema. Wichtig dabei ist es für mich den Hintergrund zu verstehen um es dann in der Praxis richtig einzusetzen. Benutzt habe ich die ein oder andere Technik schon in der Praxis, nun ist es aber an der Zeit alles zu kombinieren und im richtigen Maße zu verwenden. Mein Blog wird sich daher in nächster Zeit hoffentlich etwas mehr mit Beispielen füllen, die dann mein Genutztes und Gelerntes reflektieren sollen. Wenn, ja wenn mir neben den Vorbereitungen zum MCPD noch genügend Spielraum bleibt. Nebenbei erwähnt, habe ich auch noch eine wundervolle Frau, die meine Anwesenheit und Liebe zu schätzen weiß. Wer noch mehr Quellen zu dem Thema haben will sollte sich die Links in meinem Bloggroll ansehen. Besonders wertvoll waren für mich der Artikel über Autofac, der Blog von Ayende (Rhino.Mock) und die pnpguidance.net von David Hayden, sowie seine Seite. Der Mann hat sogar einen sehr guten Geschmack was grünen Tee angeht. Zu guter letzt noch ein deutscher Artikel, der eine gute Übersicht liefert:
Ich hoffe euch das ganze etwas schmackhaft gemacht zu haben. Feedback erwünscht.