Vorne sitzt Ralf Westphal, der Architekt, der Wissenvermittler, der Konferenzorganisator – kurzum eine .NET Lichtgestalt. Er klickt und tippt noch schnell Dinge in sein Laptop. Die Teilnehmer warten. Komisch, üblicherweise macht man Witze und redet über einige interessante Blogposts, bevor es losgeht. Ich hätte z.B. erwartet, dass einer in die Runde „Null oder nicht null, Hauptsache Ergebnis!“ wirft und so ein wenig die Runde auflockert. Doch Nein. Es liegt Konferenzduft in der Luft. Alle starren und warten.

18:45 Uhr – Es geht los: Nach ein paar einleitenden Worten und dem lieben Dank an Jan, dem Hüteträger und Evangelisten für die super Organisation der Location geht es schon los. Ralf ist am Zug. Was danach genau im Münchener .NET Coding Dojo passiert ist, beschreibt Ralf akribisch und meiner Meinung nach ziemlich treffend in seiner Retrospektive für das Coding Dojo. Inhaltlich kann ich dem kaum etwas hinzufügen und möchte mich nochmals bei Ralf für diese gute Session bedanken.

Doch ganz so unkommentiert möchte ich es dabei natürlich nicht belassen. Steffen, der vor kurzem sehr erfolgreich das Hambuger .NET Coding Dojo initiiert hatte, hat in einem Tweet seine Bedenken über den „Community-Gedanken“ geäußert. Seiner Meinung nach ist ein Coding Dojo keine „One-Man-Show“ mit Musterlösung. Ich habe ihm per Twitter schon geantwortet, möchte aber hier noch ein wenig detaillierter auf meine Auffassung eingehen.

Das „Format“ Coding Dojo

Ich hatte schon vor über einem halben Jahr einmal über das Ziel von Coding Dojo’s gebloggt. Damals, in einem Coding Dojo mit Pete, habe ich im Nachhinein mir einige Gedanken über das „Format“ Dojo gemacht. In besagtem Coding Dojo lief nämlich alles – also wirklich alles – gerade nicht so, wie es sich Pete und ich vorgestellt hatten. Wir hatten uns mit ein paar Kata’s vorbereitet und den Ablauf schon ein wenig vorgedacht. Aber es kam alles anders. Warum?

Die Antwort ist einfach: Weil wir es zugelassen haben. Wir haben eine Sache beherzigt: Ein Coding Dojo ist eine Veranstaltung für die Teilnehmer. Jeder sollte nach einem Dojo mit dem Gefühl nach Hause gehen können, dass er etwas gelernt hat. Im Coding Dojo mit dem KataBlog war den Teilnehmern die Komponentenorientierung und das IOC nicht so wichtig wie grundlegendere Themen, wie z.B. MVC als Pattern oder die HTTP-Request-Response-Pipeline von ASP.NET. Das haben wir beachtet und unseren Plan zurückgestellt.

Aber warum ein Coding Dojo ohne Coding?

Adaptiert auf das Coding Dojo von letzter Woche von Ralf lässt sich folgendes hinzufügen: Wir als Münchener .NET Coding Dojo Crew haben Ralf eingeladen, weil es die Teilnehmer – also wir, die Coding Dojo Community – so wollten. Wir haben Ralf nicht eingeladen, damit er eine Show abzieht. Wir haben Ralf auch nicht eingeladen, weil er der Ralf ist.

In einigen vorangegangenen Coding Dojo’s kam als Feedback der Teilnehmer immer wieder „zuwenig Architektur“, „zuwenig Design“, „zuwenig Vorgabe“. Als ich mit Ralf auf der VSOne darüber geredet habe, schlug er ein „Architektur-Dojo“ vor. „Super!“ dachte ich mir und freute mich, den Dojo-Teilnehmern mit einer Einladung ihren „Wunsch“ erfüllen zu können.

Wer beim .NET Coding Dojo vergangenen Mittwoch dabei war, der wird mir beipflichten, dass diesmal wirklich über Architektur, Design, Anwendungsaufbau und Komponenten-Orientierung ausgiebig diskutiert wurde. Ralf hat sein Versprechen gehalten. Er kam, dachte, designte und diskutierte. Genau so, wie es oftmals in Feedbackrunden vorheriger Dojo’s angefordert wurde.

Coding Dojo ist kein Workshop

Trotzdem. Es war anders als die vorherigen Coding Dojo’s. Ganz anders. Keine Diskussionen über die Kata-Wahl, keine Diskussion über Anforderungsanalyse, keine Design-Strittigkeiten. Statt dessen Ralf. Ralf wie er leibt und lebt. Das ist die Aufgabe, das ist die Vorgehensweise, das ist EBC, das ist State-Of-The-Art, das ist Regelwerk & Konvention. Punkt. Natürlich mit fester und stichhaltiger Argumentation und der Erläuterung der Beweggründe.

Aber irgendwie war es kein Coding Dojo so wie ich es kannte. Es gab hier und da mal Rückfragen an Ralf, „wieso“ und „weshalb“. Aber aktiv mitgemacht – aktiv Architektur gemacht – das hat meiner Meinung nach mehrheitlich Ralf getan. Ralf hat schon ab und an probiert per Rückfrage die Teilnehmer einzubinden. Doch andererseits gab es für die Teilnehmer nicht wirklich viele Optionen. Besser gesagt: Es war ein geplante Session, mit strukturierter Vorgehensweise und festem Rahmen. Da bleibt nicht viel Luft und Platz für anderes.

Man kann mir „als Veranstalter“ jetzt natürlich alles mögliche vorwerfen. Z.B. dass ich ja hätte eingreifen können, wenn es mir zu „passiv“ und zu „vorgetragen“ erscheint. Oder man könnte mir den Vorwurf machen, dass ich in den vorangegangen Coding Dojo’s einfach nur chaotisch in die Tasten gehauen habe, anstatt strukturiert vorzugehen und damit praktisch immer wieder so ein „wir brauchen Architektur“-Feedback provoziert habe. Ok, dann soll man mir die Vorwürfe machen. Meine Antwort dazu ist: Ich habe es zugelassen, weil es wichtig ist, Dinge zuzulassen. Darüber sollte man nachdenken.

Coding Dojo und Community

Jetzt transportiere ich mal meine persönliche Auffassung etwas deutlicher, damit es nicht wieder heisst, ich wäre zu objektiv oder würde mich hinter geschnörkeltem Satzbau verstecken. Ich persönlich denke, dass das letzte Coding Dojo absolut kein Coding Dojo war. Es war ein Architektur-Workshop mit Ralf Westphal. Und wenn ich das so sagen darf: Es war ein guter Architektur-Workshop. Aber es war für mich mit Sicherheit kein Coding Dojo. Es gab keine aktive Einbindung der Teilnehmer, es gab keine lockere Atmosphäre, es gab kein Coding und keine großen Diskussionen. Ich finde, das war kein Coding Dojo, wie ich es mir wünsche und wie ich es auch gut finde.

Aber meine Meinung ist nicht wichtig – das habe ich nach nun mehr als 50 Coding Dojo’s gelernt. Es ist nicht wichtig, wie ich Probleme löse. Es ist auch nicht wichtig, welches Framework ich verwende. Und es ist schon garnicht wichtig, wie ich Analyse, Architektur, Design oder Entwicklung betreibe. Denn das einzige was zählt im Coding Dojo sind die Akteure. Die Akteure im Coding Dojo sind die Teilnehmer. Das ist entscheidend.

Dojo = Lernen?

Wenn also die Teilnehmer des „Coding-Dojo’s“ mit Ralf in der Feedback-Runde sagen „Ja, das hat mir gut gefallen, ich habe super mitgemacht & viel gelernt“ – dann, ja dann ist es wohl ein Dojo gewesen. Vielleicht kein „Coding“ Dojo, aber es war ein echtes Dojo. Aber wenn die meisten kommentarlos und höflich klatschend das Dojo beenden, dann, ja dann war es wohl kein Dojo. Wie gesagt: Für mich war das kein Dojo – schon garnicht ein Coding Dojo. Aber das Feedback am Ende von Ralf’s Session war durchaus positiv. Also scheint es für einige Teilnehmer ein Dojo gewesen zu sein.

Natürlich möchte ich an dieser Stelle noch ein paar weitere Dinge loswerden. Ich möchte nicht, dass man die Definition des „Coding Dojo“‘s auf „Hat es dir gefallen?“, “Konntest Du mitmachen?” oder „Hast du etwas gelernt?“ reduziert. Ein echtes Coding Dojo hat einige weitere Parameter, die entscheidend sind für den speziellen, magischen Charakter und den guten Erfahrungsaustausch. Der aufmerksame Leser wird z.B. erkannt haben, dass ich nicht ein einziges Mal TDD erwähnt habe. Wenn Interesse daran besteht, die Bestandteile und das Format „Coding Dojo“ aus meiner Perspektive genauer kennenzulernen, dann bitte sagt mir das (schreibt einen Kommentar oder eine Email), und ich werde es niederschreiben.

Fazit & Ausblick

Abschließend möchte ich zu „Ralf’s Coding Dojo“ noch folgendes loswerden. Es war der Wunsch der Community und ich (und Ralf) haben versucht, diesem Wunsch gerecht zu werden. Es war eine gute Erfahrung. Ich habe viel daraus gelernt und ich denke, dass auch die Teilnehmer etwas mitnehmen konnten. Es war ein guter Architektur-Workshop und Ralf hat viel investiert, um den Teilnehmern seine Sicht zu zeigen und Wissen zu transportieren. Danke, Ralf.

Doch eines steht heute schon fest: das nächste .NET Coding Dojo, welches im Übrigen wieder ein ganz besonderes Dojo ist, wird mit absoluter Sicherheit ganz anders ablaufen. Nicht nur, weil diesmal nicht der Ralf eine Aufgabe stellen wird. Nein. Es wird ganz anders, weil die Partizipation und das aktive teilnehmen exemplarisch exerziert werden. Das nächste Münchener .NET Coding Dojo findet am 22. Juni im Rahmen des dotnetpro.powerday’s statt und hat den treffenden Titel „.NET Coding Dojo Empowered!“. Sei dabei und erlebe, wie man gemeinsam Lernen & Lehren kann, wie man gemeinsam eine Problemstellung mit Logik & Spaß lösen kann, wie man professionelle Software-Entwicklungs-Methoden im Team einsetzt! Es wird wieder einmal einzigartig und sehr lehrreich werden. Zur Anmeldung!

In vielen Fachblättern und Artikeln wird eine Sprintdauer von 30 Tagen (4 Wochen) vorgeschlagen. Manchmal findet man auch 2-4 Wochen als empfohlene Sprintdauer. In jedem Fall aber sollte die Sprintdauer stabil über Sprints hinweg bleiben.

Mein Einwand: Die Sprintdauer ist eine Schwachstelle in Scrum. Besser gesagt: lange Sprintzyklen sind eine Gefahrenquelle für den Erfolg von Scrum-Teams. Denn gerade lange Sprintzyklen sind für die meisten Teams der erste große Fallstrick. Die meisten Teams, die mit Scrum beginnen, fangen mit langen Sprints von 4 Wochen und z.T. sogar mehr an. Schwierig in mehrfacher Hinsicht, denn dadurch berauben sie sich eigenmächtig der Vorteile agiler Verfahren. Die Flexibilität wird eingeschränkt, die Feedbackschleife des Inspect & Adapt wird verlängert und dem Team wird hohe Planungskompetenz bzw. -verantwortung aufgebürdet.

Was kann man tun um diesen Risiken entgegenzuwirken? Ganz einfach: Kurze Sprints! Mit kurzen Sprints meine ich auch kurze Sprints. Aus meiner Sicht ist die ideale Sprintdauer eine Woche lang. Ja, richtig gelesen, nur 5 Werktage! Jede Woche Planung, jede Woche Review, jede Woche Retro.

Daily Scrum, Weekly Sprint

Was erreicht man dadurch? Zunächst einmal schafft man durch so eine kurze Sprintdauer eine hohe Planungsfrequenz. Das ist für fast alle Beteiligten nur von Vorteil. Der PO hat hohe Flexibilität, während das Team einen sehr überschaubaren Planungszeitraum hat. Das Team geht genauer auf die Stories und das Design ein, bricht in der Planung genauer Tasks auf. Dadurch ergeben sich quasi automatisch verbesserte Schätzung und stabiles Commitment. Das wiederum stärkt die Vorausplanung und Releaseabstimmung auf der Product Owner-Seite.

Ein-Wochen-Sprints bedeuten aber auch schnelleres Inspect & Adapt. Jede Woche gibt es eine Retrospektive, das wichtigste agile Gremium in Scrum. Jede Woche eine Retrospektive zu haben ist ein wenig wie “und wöchentlich grüßt das Scrumeltier” – es kommen Anfangs immer wieder die gleichen Themen ins Gespräch. Das liegt vor Allem daran, dass es viel einfacher ist, wöchentlich “inspect” zu betreiben, als effektiv “adapt” durchzuführen. Doch genau das ist das schöne am schnellen, wöchentlichen Sprint-Puls. Es wird die Agilität förmlich “antrainiert”. Das Team lernt wesentlich schneller, wirklich zu adaptieren, anstatt es irgendwie auf die lange Bank zu schieben.

“Accelerate” für eine gute “Velocity”

Ein nicht ganz auf den ersten Blick erkennbarer Vorteil der Wochensprints ist der schnelle “Ramp-up” des Teams zur stabilen Velocity. Während ein Team mit 4-Wochen-Sprints nach den ersten 3-5 Sprints (also nach 3-5 Monaten!) erst so halbwegs stabile Produktivität und Schätzkompetenz aufweisen kann, gelingt einem Team mit Wochensprints nach der gleichen Sprintzahl (also nach 3-5 Wochen) noch mehr. Ergo: Ein zügiges Teaming wird erreicht.

Gerade Wochensprints haben meiner Meinung nach die Bezeichnung “Sprint” verdient. Denn wöchentliche Iterationen “fühlen” sich nicht nur wie ein Sprint an, sondern sind auch so intensiv und ergiebig wie ein Sprint. Das liegt nicht nur am höheren Takt, sondern auch an einer ganz lapidaren Tatsache: Die Arbeitswoche.

Unsere gesamte Lebens- und Arbeitskultur tickt in diesem “Wochentakt”. Viele denken, planen und organisieren in Wochenzyklen. Das kommt auch dem wöchentlichen Scrumsprint zu Gute. Teams mit Wochensprints kommen mit dem Wochentakt “einfach besser zurecht” – wissentlich oder unwissentlich. Höchstwahrscheinlich ist dies dem Fakt geschuldet, dass die gesamte Arbeitswelt sich an diesem Takt orientiert. Egal ob nun Scrum oder nicht, die Kalenderwoche ist und bleibt eine präsente Zeiteinheit, die für Planung, Vereinbarung und Organisation angewendet wird.

Kurz und Knackig

Bei all den Vorteilen, die eine kurze, nach meinem Ermessen am Besten wöchentliche Sprintdauer hat – es gibt auch hier wieder einige Dinge, die man vor der Einführung oder beim “Sprinten” beachten sollte. Ein allgemeiner Fallstrick kann es werden, die Planung des Sprints auf den Montag zu legen, und die Retrospektive auf den Freitag. So wie es bei klassischen Jour-Fixe Meetings zum guten Ton gehört Planungsgespräche an das Ende der Woche zu legen, ist das bei Wochensprints auch förderlich. Eine mögliche Variante wäre es, die Planung auf den Freitag zu legen und Review/Retro auf Montag.

Damit ist der nächste Achtungspunkt schon implizit genannt: Nicht versuchen, alle “Scrum-Meetings” in einen Tag zu quetschen. Ganz im Gegenteil, die Planung kann Freitag vormittags erfolgen. Der Nachmittag ist reserviert für Konzentrationsarbeit, Tageskommunikation, Vorbereitung des Boards und des Reviews / Retro’s.

Montag ist vormittags “Tabu” – denn genau dann befindet man sich in der “Twilight Zone”. Ende des letzten Sprints oder Anfang des nächsten Sprints – schon durch die Planung oder noch im Review – noch Montagsmüde oder schon im Tatendrang – ein Montag Morgen eben. Der späte Nachmittag kann dann nach dem üblichen Daily für die kurze Review/Retro investiert werden. Bei Wochensprints ist eine 4 stündige Planung angemessen, eine Review/Retro von einer Stundes komfortabel ausreichend.

Fazit: Kurz & Knackig – das ist die bessere Sprintdauer in Scrum!
Es gibt natürlich noch mehr Aspekte als die aufgeführten, um zu einer ausgewogenen Sprintdauer für sein Team zu kommen. Für mich bleibt jedoch die in den meisten Fällen zutreffende Erkenntnis: Kurz & Knackig ist besser als Lang & Weilig. Was denken Sie? Ihre Meinung ist gefragt!

Phase 1:

Momentan befindet sich der Umbau in Phase 1. In dieser ersten Phase baue ich Wordpress als Blog/Site-Tool ein wenig aus. Der Works-Bereich wird dabei immer noch mit Mediawiki betrieben. Dieser erste Schritt dient der Umgestalung der Website ansich sowie der Vorbereitung im Hintergrund auf die gesamte Verwaltung der Site mit Wordpress.

Phase 2:

In der  zweiten Phase wird der Protierung des Contents von Mediawiki nach Wordpress vorangetrieben, Durch den massiven Content, der im Mediawiki entstanden ist, wird diese Phase wohl etwas länger dauern. Hier möchte ich insbesondere die einzelnen Versionen und die Datumsinformationen beibehalten. Das wird sicher eine kleine Herausforderung.

Phase 3:

Die dritte und letzte Phase ist das sog. “Polishing”. Hier werde ich Mediawiki abschalten und den alten Content archivieren. Darüber hinaus wird die Website noch mit einigen kleinen Features und Gimmicks angereichert werden. Es wird wohl auch so sein, dass das Layout der Website nochmals überarbeitet werden wird.

Ich werde über den Status der Umbauarbeiten natürlich berichten ;-)

Genauer gesagt ist es Uncle Bob, der mit seinem provokanten Satz “Craftsmanship over Crap” auf der Agile’08 die Diskussion angestoßen hat. Natürlich spielt da auch sein Buch Clean Code eine besondere Rolle. Im Prinzip regt sich Uncle Bob darüber auf, das heutzutage immer mehr Agile Software-Entwicklung mit “schnell fertigstellen”, “mal ändern” und “iterativ ausbauen” gleichgesetzt wird, ohne wirklich qualitativ wertvolle Ergebnisse abzuliefern.

Er spricht mir aus der Seele. Wie oft habe ich schon einfach runtergerotzten Code gesehen, wo nichts anderes zu erkennen war außer einem Haufen zusammengelegter Klassen und Methoden. Wie oft habe ich diesem bescheuerten Satz “das wurde mit der heißen Nadel gestrickt” gehört, wo ich mir selbst die Frage stellte, ob ich nun in einer Arbeitsgemeinschaft für Strickpulli-Anfänger gelandet bin oder ich doch noch in der Software-Branche bin.

Das erschreckende ist ja nicht nur, dass diese “agilen” Software-Produkte nicht nur durch den Druck von Geschäftsleuten, Produktmanagern oder sonstigen “Stakeholder”n getrieben wird. Mittlerweile ist die niedrige Qualität schon in das Innere von Software-Entwicklern vorgedrungen. Es gibt Kollegen, die kümmern sich einen feuchten um qualitativ hochwertige Ergebnisse, sondern verfolgen stur das, was man Ihnen vor die Nase legt. Erstaunlicherweise ist es meist dieser Typus Entwickler, der sich dann auch noch als “State-of-the-Art”-Developer verkauft, weil er “business-minded” und “agile” ist. Das Fass zum überlaufen bringt dann meistens die Argumentation, dass man heutzutage ja “iterativ” und “test-driven” entwickelt, und dabei wirklich nur das notwendigste implementiert.

Also nicht, das man mich jetzt falsch versteht: das soll jetzt keine Hommage an den alten Wasserfall werden. Mittlerweile ist es klar, das man Software-Entwicklung iterativ wesentlich besser vorantreiben kann. Auch viele Patterns und Practices beschäftigen sich mit der Verbesserung der Entwicklung und der Qualität. Fakt ist allerdings auch, dass durch die rasante Entwicklung der Methoden, der Branche, des “Businesses” durch das Web und nichtzuletzt durch die zahlreichen Tools die eigentliche Schule der Entwicklung von Software immer mehr vernachlässigt wird.

Da kommt meiner Meinung nach die von Uncle Bob initiierte Bewegung genau zur richtigen Zeit. Mit vielen anderen Software-Entwicklern, die noch die Fahne der Kunst hochhalten, hat er das “Manifesto for Software Craftsmanship“ ausgearbeitet. Es ist eine Analogie – oder besser ein Addendum – zum klassischen Agile Manifesto:

• Es geht nicht nur um funktionierende Software, sondern auch um gut entwickelte Software
• Es gilt nicht nur Änderungen zu verarbeiten, sondern auch um stetige Wertsteigerung
• Es verlangt nicht nur Austausch von jedem Einzelnen, sondern auch Zusammengehörigkeit durch Gruppenbildung von Profi’s
• Es braucht nicht nur Kundenkommunikation, sondern auch eine produktive Partnerschaft

Genau diese Werte sind es, die einen Software-Entwickler zu einem guten Software-Entwickler machen. Naja, ganz neu sind diese Wertvorstellungen ja nicht, zumal man ja schon vor Jahren relativ formal mit Hilfe der ISO 9126 Qualitätsrichtlinien einen Ansatz gefunden hat, eine “Qualitäts- und Professionalitätsethik” abzuleiten. Noch einen Schritt weiter geht da die (mittlerweile auch schon einige Jahre alte) Definition der Code Of Ethics in Software Engineering von ACM.

Nichtsdestotrotz ist die neue Craftsmanship-Bewegung notwendig und wichtig. Dem tragen auch Ralf Westphal und Stefan Lieser Rechnung, in dem sie auf ihrer neuen Website clean-code-developer.de ein an Uncle Bob angelehntes Wertesystem beschreiben. Dieses Wertesystem beinhaltet eine Reihe von guten Regeln und Vorschlägen, wie man als Software-Entwickler sein Werk und Tun verbessern kann. Ich persönlich finde das von Westphal & Lieser propagierte “Grad-System” (ähnlich wie bei Judoka) nicht zielführend. Es ist vielmehr irreführend und transportiert implizit das “ich habe den blauen Grad, also bin ich besser als Du” Gefühl, obwohl dies bestimmt nicht so gemeint ist. Also ich werde sicherlich kein “Clean Code Developer”, ich sehe mich eher als ein “Software Craftsman”. Nichtsdestotrotz findet man auf der Website gute Ratschläge.

Was für mich zählt, ist die Tatsache, das ich immer versuche, eine bessere Arbeit abzuliefern als je zuvor. Ich bin stolz auf meine Arbeit und meinen Beruf.

• Oslo – Model Driven Development, Dariusz Parys
• Visual Studio 2010 (Codename Rosario), Christian Binder
• WCF & WF in .NET 4.0, Dariusz Parys
• ASP.NET Futures, Oliver Scheer

Die erste Session über Oslo habe ich schon hinter mir. Ein Log dazu gibt’s nach der Summit, es sei nur kurz erwähnt: interessante Abstraktionen! Mal sehen, wie die restlichen Sessions werden.

Session 1: Steve Teixeira über Multi-Core Software-Entwicklung

Steve Teixeira ist Program Manager beim Parallel Developler Tools / Visual Studio Team in Redmond und hatte in seiner Session neben der grundlegenden Einführung der neuen API für Multithreading auch einige Neuigkeiten über die nächste Visual Studio Version zu berichten. Doch alles der Reihe nach. Zunächst einmal schilderte Steve, wieso man sich eigentlich Gedanken über Parallele Ausführung von Code machen sollte. Der Grund ist natürlich bei der Hardware-Entwicklung vergraben, denn mittlerweile gelangt man an die Leistungsgrenzen im CPU-Design mit einem Kern. Der Hauptgrund ist die inzwischen fast unkontrollierbare Wärmeleistung, die die Chips von sich geben. Der Trend ist zu Multi-Core-CPU’s ist eindeutig auch im Alltag angekommen.

Das wiederum macht es erforderlich, die Software auf die neuen Gegebenheiten anzupassen. Steve zeigte ein schönes Beispiel mit Hilfe von PLINQ um die Unterschiede zwischen sequentiellem und parallelisiertem Code deutlich zu machen. Was heißt das für den “Alltags-Entwickler”, wie ich es z.B. bin? Nun, zunächst einmal bedeutet es eine Schärfung der Coder-Sinne auf das Thema Performance. Ich fühle mich zwar in diesem Thema schon heute gut aufgehoben, aber es dürfen ruhig noch ein wenig mehr Details sein.

Unterstützt wird dies im Besonderen durch das neue Visual Studio 2010. Es kommt mit neuen Tools wie Performance und Concurrency Profilern, die deutlich, graphisch anschaulich zeigen, wieviel Zeit die Software für bestimmte Aktionen verbraucht und mit welchen Ressourcen diese Leistung erreicht wurde. Auffällig dabei sind auch die Optionen, die das neue Performance-Tool bietet: CPU-basiertes Sampling, komplette Instrumentation, also Analyse aller Zeiten und Zyklen von Methodenaufrufen und das schon eben erwähnte Concurrency Profiling, mit dem man in der Lage ist zu erkennen, wie die Threads mit den Aufgaben ausgelastet sind.

Eine “Performance Debugging Suite” also, die im neuen Visual Studio verankert sein wird. Voraussetzung ist jedoch die Installation auf Windows Vista oder Windows 2008, da die Monitoring-Tools intern eng mit der seit Vista erweiterten Windows Eventing API (ETW) zusammenarbeiten.

Für so passionierte .NET-Entwickler wie mich ist die Verwendung der neuen API einfacher als erwartet. So lassen sich z.B. LINQ-Abfragen elegant mit dem “Anhängsel” .AsParallel() parallelisieren. Mindestens genauso einfach lassen sich auch Codebestandteile für die Parallel-Ausführung trimmen. Eine einfache for-Schleife ist mit Parallel.For() im Nu für die Parallelisierung umgesetzt. Die Nebeneinanderausführung von separaten Codeteilen mit Parallel.Invoke() ist zügig definiert und intuitiv. All diese Dinge sind fest im neuen .NET Framework 4.0 verankert. Interessant in diesem Zusammenhang ist, das Steve explizit auf deutliche Verbesserungen “unter der Haube” hingewiesen hat. So ist z.B. die ThreadPool-Klasse intern mit neuen Strategien wie dem Work Stealing ausgestattet worden, um die Verteilung der Aufgaben in Multi-Core Umgebungen zu optimieren.

Ein helles Ohr hatte ich auch bei den vielen kleinen Anekdoten und Anmerkungen von Steve. So ging er flüchtig auf die Entwicklung von Visual Studio ein und verriet, das der Visual Studio Code mehrheitlich in C++ und C# geschrieben ist und derzeit mehr als 45 Millionen Codezeilen umfasst. Interessant ist auch die Tatsache, dass das Visual Studio Team bei der Entwicklung von neuen Komponenten und UI verstärkt WPF im Einsatz hat. Steve begründet das mit der schlichten Tatsache, das WPF schnell genug ist und eine wesentlich effizientere UI-Entwicklung ermögliche als mit der klassischen GDI.

Fazit: Ein absolutes Highlight – Visual Studio 2010 in Aktion und Insider-Wissen. VS10, Parallels & .NET 4.0, ich warte auf euch…

Session 2: Holger Schwichtenberg und AJAX Services

AJAX ist nicht nur in aller Munde sondern heutzutage schon fast auf jeder Website in irgendeiner Form im Einsatz. Das man AJAX auch in ASP.NET einsetzen kann, ist spätestens nach dem .NET Framework 3.5 keine besondere Neuigkeit mehr. So auch der Inhalt der Session von Holger. Er machte einen knapp einstündigen Rundflug über die Möglichkeiten des AJAX-Einsatzes in ASP.NET, darunter das berüchtigte UpdatePanel (aka. AJAX für Arme), das AJAX Control Toolkit (aka. Atlas) und die kleinen Tools, die mit den ADO.NET Data Services einhergehen.

Auf AJAX-Spezifische News für .NET 4.0, den JQuery-Support mit ASP.NET 4.0 oder Visual Studio 2010 ging Holger garnicht oder nur am Rande mit einem Keyword aus einem Slide ein. Schade, aber aus meiner Sicht eine sehr schwache und fachlich “äußerst überschaubare” Session. Besonders die Argumentationen von Holger für so manche Technologie sind in meinen Augen etwas zu oberflächlich. So geschehen bei einer Frage eines Zuhörers:

Zuhörer: Bei den ADO.NET Data Services verzichten Sie auf eine gewohnte 3 bzw. N-Tier Architektur. Dies wurde lange als “Best Practice” vermittelt und nun wird das mißachtet. Was meinen Sie?

Schwichtenberg: Nun, ich sage Ihnen ja nicht, das eine N-Tier Architektur nicht empfehlenswert ist. Aber – mit ADO.NET Data Services ist der Betrachtungswinkel ein anderer. Während “klassische” Web Services nur die Daten und Funktionen herausgeben, die wirklich benötigt werden – also praktisch die Daten schon serverseitig Filtern – wird bei den ADO.NET Data Services zunächst der gesamte Datenbestand im Web Service angeboten. Der Client kann nun über die REST-Query entscheiden, was er konkret benötigt. Aus meiner Sicht ist diese Herangehensweise ein Produktivitätsgewinn.

Na, das ist ja eine feine Aussage! Sichereitsbedenken scheint Holger nicht zu haben, wenn er alle Daten frei verfügbar macht. Des Weiteren ist die Konstellation AJAX + ADO.NET Data Services + Entity Framework sehr wohl eine “Tiered Architecture”, Das Entity Framework löst den klassischen Data Layer ab. Die Data Servies können als “Business Layer” durchgehen (man kann ja selbst noch einiges dazu entwickeln und der Zweck eines “Data Providers” kann in meinen Augen auch als “Business” definiert werden). Zu guter letzt ist AJAX bzw. die Website die UI bzw. das Frontend. Naja, vielleicht habe ich es auch nicht richtig kapiert, was Holger damit gemeint hat.

Fazit: Eine der schwächeren Sessions, die fachliche Tiefe und vor Allem Neuigkeiten bzw. Best Practices vermissen ließ.

Session 3: Dariusz quatscht hessisch, und zwar “Windoos Äschär”

Der Name ist Programm: Dariusz wagt sich in die neue blaue Windows-Welt: “Windoos Äschär” – so meint er könnte man es zumindest versuchen, die neue Service-Familie auszusprechen. In wohl bekannter Manier stieg er fröhlich in die Thematik mit einem Überblick ein.

Da wären zunächst die .NET Services “Access Control”, “Service Bus” und “Workflow”. Der Access Control Dienst so etwas vergleichbares wie ein etwas besserer, Claims-basierter Single-Sign-On Service mit Authorisierungsmanagement. Über eine Claims-Challenge können sich Nutzer und Dienste gleichermaßen authentifizieren. Dabei kann man aus der gewohnten Variabilität der Authentifizierungsart wählen – ob nun UserNamePassword, Zertifikate, Windows Live ID – Claims bleibt Claims. Der Service Bus ist der aus größeren Unternehmen bekannte ESB portiert auf die “Cloud”. Mittelfristig soll mit dem Service Bus eine “orchestrierte” Gemeinde von Diensten zur Verfügung gestellt werden. Das Pattern ist jedenfalls nicht neu. Der dritte im Bunde ist der Workflow Dienst. Basierend auf der WF kann er als “Schaltzentrale” verwendet werden. Momentan ist dieser Baustein noch sehr rudimentär, soll aber weiter ausgebaut werden.

Eine weitere Service-Gruppe ist die “SDS” – die SQL Data Services. Gleich zu Beginn klärt Dariusz hier den Unterschied zwischen “Azure Storage” und den “echten” SQL Diensten. Während die Storage eher eine “einfache, sqlfähige Datenablage” ist, sollen die SDS mittel- bis langfristig wesentlich mehr Features anbieten wie z.B. Reporting, Data Mining oder ETL Dienste. Gewöhnungsbedürftig bei den SDS ist die Organisation der Daten: Man hat nicht mehr die klassischen, relationalen SCHEMA TABLE ROW Strukturen. Statt dessen befinden sich die Daten in sog. “Containern” (vergleichbar mit Datenbanken oder Schemata). Die Daten wiederum sind als “Entities” strukturiert. Eine Entity hat mindestens einen Typ (also den Entity-Namen), eine EntityID und den EntityKind, welche Aussage über die Art oder Klasse der Datenstruktur geben soll. Weitere Felder sind frei definierbar. Die Feldtypen beschränken sich derzeit nur auf einfache Datentypen.

Auf weitere Dienst-Gruppen ist Dariusz nicht eingegangen – wie sollte er auch – er hatte während der Session mit anderen Problemen zu kämpfen. Jede zweite Demo ging nicht oder brach mit irgendwelchen Exceptions ab. Tja, er musste selbst zugeben, das “Äschär” noch nicht ganz fertig ist und an der einen oder anderen Stelle die notwendige Reife für den produktiven Einsatz vermissen ließ.

Der erste Eindruck den Windows Azure und die “SOA-Diensten” hinterlassen ist das Interesse an Neuem mit einer großen Portion Skepsis. Auch wenn irgendwann einmal Azure stabil und schnell wird bleibt abzuwarten, ob die Plattform attraktiv und intuitiv genug ist, um echte Anwendungen darauf laufen zu lassen.

Fazit: Mal sehen was daraus wird!

Session 4: Dirk Primbs schreibt effizienten Code in C# 3.0

Dirk ist eines der bekanntesten Gesichter auf Konferenzen – kein Wunder, schließlich ist er seines Zeichens Developer Evangelist bei Microsoft. Die heutige Session hatte die Überschrift “Effizienter Code in C# 3.0″ – das hörte sich vielversprechend an. Also dachte ich mir, wenn ich schon nicht in die Session von Berndt gehen kann (er war leider nicht anwesend und wurde durch Dariusz vertreten), dann höre ich mir mal an, was Dirk mir über Effizienz mit C# 3.0 zu erzählen hat.

Leider war nicht ganz in dem Paket drin was draufstand. Dirk verbrachte über die Hälfte der Zeit damit, die Geschichte von .NET und C# zu erzählen. Angefangen bei C# 1.0, über C# 2.0 bis zum aktuellen C# 3.0. Die aktuelle 3.0-Version kam dabei für meine Begriffe viel zu kurz. Dirk vermittelte in seiner Retrospektive über C# 2.0 sehr gut, was Generics, Anonymous Methods und Discrete Property Accessors sind. Doch besonders prickelnd war es nicht gerade, mittlerweile gängige Konstrukte nochmals vorgekaut zu bekommen. Mit C# 3.0 hatte das wenig zu tun, und mit effizientem Code auch nicht.

Wahrscheinlich habe ich mir unter dem Titel “Effizienz” etwas anderes vorgestellt als Dirk. Er ging auf Syntax und “eleganten” Code ein, wo ich eher Effizienz-Vergleiche zwischen konkrekten und anonymen Typen erwartet hätte. Dennoch war es nicht langweilig – wer Dirk schon öfter erleben durfte, der weiß warum.

Es blieb am Ende doch noch eine gute Viertelstunde übrig, um auf neue Sprachkonstrukte und Features von C# 3.0 einzugehen. Type Inference und das var Keyword, Object Initializer und Automatic Properties. Wie zu erwarten war, wurde die Verwendung des var Keywords “angeregt” diskutiert. Ich hatte mich in einem Post ja schon über den Sinn und Zweck von var geäußert. Äußerst bedauernswert fand ich allerdings, das kein Sterbenswörtchen über C# 4.0, die DLR, das dynamic keyword oder Duck Typing verloren wurde. Zumindest ein Ausblick und ein kurzer Rundflug wäre schön gewesen.

Fazit: Eine Mischung aus “Basics Workshop”, Human FxCop und OpenSpace Talk – locker, bekömmlich, bekannt.

Soviel zum ersten Tag. Mal sehen, was der zweite bringt… :-)

Sind Inline-Kommentare schlecht ?

Neal behauptet, Kommentare wären ein Bruch des DRY-Prinzips, denn schließlich hätte man das essentielle ja schon im Code. Diesen nochmals zu kommentieren wäre eine Wiederholung dessen, was man ohnehin schon programmiert hätte.

Ganz so einfach ist das leider nicht. Es gibt viele Situationen, in denen Kommentare in gut geschriebenem Code hilfreich sind. Die pauschale Aussage, Kommentare würden gegen DRY verstoßen, ist schlichtweg naiv. Wichtig bei Inline-Kommentaren ist es, darüber zu schreiben, wieso man den Code in der gegebenen Form aufgebaut hat. Eine “stupide” Wiederholung der Statements wie z.B.

/* create new account */
IAccount account = new Account();

ist sicherlich eine unnötige Wiederholung. Aber ist dadurch der Code (also IAccount account = new Account();) automatisch schlecht? Ich würde sagen: Nein.

Das Inline-Kommentare auch besonders wertwoll sein können, verschweigen die meisten. Zumindest diejenigen, die behaupten Kommentare seien ein Code Smell. Nehmen wir z.B. folgendes Code-Fragment aus einem HttpModule:

private void ResetSessionCookieDomain(HttpApplication application)
{
	string host = application.Request.Url.Host;
	if (application.Session.IsNewSession && !application.Request.Url.IsLoopback)
	{
		HttpCookie appCookie = application.Request.Cookies[this.GetApplicationCookieName()];
		if (appCookie != null)
		{
			appCookie.Domain = this.GetCookieDomain();
		}
	}
}

Auf den ersten Blick sieht das ja schon ziemlich aufgeräumt und verständlich aus. Aber der erste Blick trügt. Denn diese Methode wird mindestens drei mal unterschiedlich interpretiert werden.

Derjenige Entwickler, der wenig oder keine Erfahrung mit ASP.NET hat, wird den Code so hinnehmen wie er ist und ihn falsch verstehen. Er wird annehmen, das man in ASP.NET Cookies ausschließlich über das HttpRequest-Objekt zugreift und dort ändern, erstellen oder löschen kann.

Derjenige Entwickler, der sehr große Erfahrung in ASP.NET hat, wird den Code auch so hinnehmen wie er ist und ihn richtig interpretieren (dazu später mehr).

Derjenige Entwickler, der einige Erfahrungen in ASP.NET gesammelt hat, wird sich über den Code wundern und sich selbst die Frage stellen, wieso der Entwickler der den Code geschrieben hat gerade über HttpRequest das Cookie verändert. Schließlich gibt es ja den HttpResponse, der auch eine Cookies-Eigenschaft hat (HttpCookieCollection).

Im Ergebnis hat es die obige “saubere”, unkommentierte Methode geschafft, in drei verschiedenen Köpfen verschiedene Ausrufe- und Fragezeichen zu hinterlassen. Dabei wäre es ziemlich einfach, diese Mehrfachinterpretation durch einen kurzen Kommentar zu vermeiden:

private void ResetSessionCookieDomain(HttpApplication application)
{
	string host = application.Request.Url.Host;
	if (application.Session.IsNewSession && !application.Request.Url.IsLoopback)
	{
		/* Careful: when handling cookies using the response object new cookies are set.
		 * The cookie collections in the Request and Response objects are always synchronized in .Net.
		 * The request object is used to reset the domain and avoid generating a new cookie accidentally. */
		HttpCookie appCookie = application.Request.Cookies[this.GetApplicationCookieName()];
		if (appCookie != null)
		{
			appCookie.Domain = this.GetCookieDomain();
		}
	}
}

Ist das jetzt ein Code Smell? Neal behauptet ja, denn für Ihn ist die einzige Rechtfertigung für Inline-Kommentare ein komplexer Algorithmus. Ich behaupte: Nein, das ist kein Code Smell, sondern vielmehr eine Bereicherung des Codes. Ich bin mir fast sicher, das auch er den Kommentar schätzen würde, wenn er mit dem Code konfrontiert wird.

Kommentare: Störfaktor oder Dokumentationsbasis ?

Ein weiteres Argument von Neal gegen Kommentare – genauer gesagt gegen kommentierte Methoden im JavaDoc oder NDoc (<summary/>) Stil – ist der Störfaktor, der von Kommentaren ausgeht, wenn man refaktorisiert. Als ich das gelesen habe, konnte ich mir ein Schmunzeln nicht verkneifen. “Was ist denn das für eine fadenscheinige Ausrede” habe ich mir gedacht. Natürlich sind Kommentare, aus denen Dokumentationen generiert werden ein zweischneidiges Schwert. Auf der einen Seite sind sie ein weiteres, zu erstellendes und pflegendes “Code-Fragment”, auf der anderen Seite blähen sie den Sourcecode um etliche Zeilen auf und lenken von dem eigentlichen Code ab.

Ich persönlich habe bis Dato keinen Entwickler getroffen, der beim Entwickeln von Code gleichzeitig dokumentationsbasierte Kommentare erstellt hat. Es macht ja auch faktisch keinen Sinn, wenn man als Entwickler davon ausgeht, das man den Code sowieso noch mit großer Wahrscheinlichkeit ändern oder umstrukturieren muss. In einigen Fällen macht es sogar gar keinen Sinn, z.B. wenn man Prototypen entwickelt oder kleine, temporär verwendete Tools.

In einem professionellen Umfeld jedoch, wo Sourcecode ein oder sogar das einzig große Kapital eines Unternehmens ist, sind Dokumentationen allgemein ein hohes Gut. Dazu gehören nun mal auch die dokumentationsbasierten Code-Kommentare. Als Entwickler oder Entwicklungs-Team muss man sich natürlich die Frage stellen, wann und wo solche Kommentare einen effektiven Mehrwert liefern. Zumeist sind es in allererster Instanz hochgradig wiederverwendete Komponenten und Klassen, z.B. in Frameworks oder aber auch Schnittstellen. Ist der Sourcecode auch noch Teil eines Produktes, wie z.B. bei einer API, so muss dieser auf jeden Fall gut und ausreichend ausführlich kommentiert werden.

Hat man nun z.B. ein solches, gut kommentiertes Framework vor sich und muss es erweitern oder verändern, so ist es keinesfalls ein Grund, eine notwendige Refaktorisierung nicht oder nur unvollständig durchzuführen, weil die Kommentare existieren. Jeder, der sich selbst bei so einer Situation ertappt, das er nur den Code refaktorisiert oder garnicht refaktorisiert, weil er die “lästigen” Kommentare auch noch überarbeiten muss, sollte sich die Frage stellen, ob er den Ansprüchen in professionellen Umgebungen gerecht werden kann.

Unit Tests vs. Kommentare

Eine interessante Argumentation von Neal ist, das Tests den Code wesentlich besser dokumentieren als Kommentare. Dabei stelle mir die Frage, was denn Tests und Kommentare eigentlich gemeinsam haben. Verifizieren Kommentare die Funktionstüchtigkeit einer Methode? Dokumentieren Tests wieso ein Entwickler die Klasse oder Methode implementiert hat? Ich jedenfalls habe keines von beiden in der Art und Form durchführen können.

Neal stützt sich bei der “Unbrauchbarkeitsrechtfertigung” von Kommentaren nicht nur auf klassische Unit Tests, sondern auch auf den Einsatz von BDD-Frameworks wie z.B. NBehave oder StoryQ. Diese “ausführbaren” und damit auch testbaren Spezifikationen sind eine gute und besonders hilfreiche Bereicherung für die Software-Entwicklung. Ich habe NBehave schon eingesetzt und bin positiv angetan von den neuen Möglichkeiten, die solche Frameworks für die Software-Entwicklung eröffnen.

Kommentare im Kontext

Jedoch ist es keinesfalls sinnvoll, Unit Tests oder BDD mit Code-Kommentaren zu vergleichen. Der gemeinsame Nenner, den alle drei Dokumentationsformen haben, ist schlichtweg die Intention, den Code zu dokumentieren.

Dabei konzentrieren sich BDD-Stories auf die funktionale Spezifikation der zu erstellenden Software. Unit-Tests dokumentieren die funktionale und/oder technische Verifikation von Software. Code-Kommentare dienen der Beschreibung und Vermittlung essentieller technischer Implementierungsdetails von Software. Zusammengefasst also drei verschiedene Dokumentationsformen, die alle ein anderes Ziel verfolgen. Aus meiner Sicht sind sie nicht miteinander vergleichbar.

Aber überall wird behauptet, Kommentare seien “smelly”…

…jedoch ist das nicht ganz richtig. Denn “überall” wird das sicher nicht behauptet – ein Gegenbeispiel liest Du gerade. Aber es ist richtig, das es neben Neal noch weitere, z.T. hoch angesehene Quellen gibt, die behaupten, Kommentare seien ein Code Smell. Ein sehr prominentes Beispiel ist Jeff Atwood; in seiner Code Smells Liste sind Kommentare ganz oben.

Es lohnt sich hier jedoch, die Aussage genau zu lesen und auch kritisch zu hinterfragen. Denn in den meisten Fällen werden Kommentare nur als “Code Smell” deklariert, weil man entweder schlechte Erfahrungen mit Kommentaren gemacht hat oder selbst keine guten Kommentare schreiben kann. Und schon wird aus einem für mein Dafürhalten wichtiges Artefakt wie den Kommentaren ein Warnsignal für schlechten Code gemacht. Auch hier gibt es wieder einen feinen Unterschied, denn ein Code Smell ist für mich ein echtes Warnsignal, das etwas schief läuft. Die Argumentationen vieler, die Kommentare als Code Smell sehen, berufen sind jedoch kaum auf schlechten Code-Stil als auf allgemeine “Probleme” mit Kommentaren.

So wird oft zitiert, das Kommentare falsch geschrieben werden, wenn Sie nicht das “Warum?” erklären, sondern einfach nur beschreiben was gerade passiert. Es wird behauptet, Kommentare würden einen in die Irre führen, weil sie falsch oder nicht gepflegt sind. All das sind allerdings generelle Probleme des kommentierens, weniger ein Problem des kommentierten Codes.

Im Übrigen gibt es genügend Entwickler, Artikel und Bücher, die sich mit der Thematik Inline- und Code-Kommentare auseinandersetzen. Zum Beispiel gehen Andrew Hunt und David Thomas in ihrem legendären Buch The Pragmatic Programmer auf Kommentare und Dokumentationen in Punkt 44 “It’s all Writing” ein und erklären verständlich, das gutes kommentieren von Source Code unerläßlich für gute Qualität und die weitere Entwicklung ist.

Ich möchte natürlich auch Martin Fowler und sein Buch Refactoring nicht unerwähnt lassen. Fowler deklariert dort Kommentare als Code Smell – liest man jedoch seine Argumentation, warum Kommentare ein Code Smell sein können, landet man schnell wieder bei der Erkenntnis, das es hier um falsche Kommentare geht, und nicht um schlechten Code. Er gibt im Buch dennoch die folgende konrekte Handlungsanweisung:

When you feel the need to write a comment, first try to refactor the code so that any comment becomes superfluous.

Entscheidend für mich ist der Anfang des Satzes: “When you feel the need to write a comment…”. Es geht ihm also nicht darum, Kommentare zu eliminieren oder aber den Sinn von Kommentaren zu hinterfragen, sondern vielmehr um die Tatsache, das man versuchen sollte, den Code so gut wie möglich selbsterklärend zu schreiben. Das dies nicht immer der Fall sein kann oder in manchen Situationen nicht adequat ist, ist für Fowler selbstverständlich. Aus meiner Sicht ist die obige “best practice” eine gute – aber keine schlüssige Argumentation für einen Code Smell.

Kommentare sind gut und wichtig

Aus all den Betrachtungen heraus kann ich für mich nur den Schluß ziehen, das Kommentare gut und wichtig für qualitativ hochwertige und wartbare Software sind. Natürlich sollte – wie bei so vielen Dingen in der Programmierung – auf den richtigen Einsatz und die richtige Dosierung von Kommentaren geachtet werden. Wie auch für den Code selbst gilt für Kommentare, das sie erstellt und gepflegt werden müssen. Manchmal muss man sie auch löschen oder verbessern – genauso wie beim Code selbst. Entscheidend für mich beim Kommentieren ist, das ich es mindestens so durchführe, wie ich es beim ersten Lesen meines eigenen Codes erwarten würde, damit ich den Code schnell und gänzlich verstehe.

Fazit: Comments are a good thing (if you know how to use them).

Anfangs war ich vom Einsatz und den Möglichkeiten, die durch var entstehen sehr angetan. Ehrlich gesagt bin ich das heute noch. Aber mein Enthusiasmus ist doch deutlich gedämpft, jetzt wo ich es im Einsatz sehe und selbst einsetze. Mein “Problem” (wenn man das so überhaupt sagen kann) mit var ist nicht die Typ-Inferenz die es ermöglicht, sondern eher der zuweilen exzessive Einsatz.

Besonders betrübt bin ich, wenn ich z.B. in populären Blogs wie dem von Jeff Adwood lesen muss, das var das Allheilmittel schlechthin ist und so oft wie nur irgendmöglich eingesetzt werden sollte. Bei solchen Aussagen liegt bei mir die Vermutung nahe, das Jeff gerade nicht sehr große Projekte in C# stemmt. Schließlich wurde var nicht erfunden um die Deklarations- bzw. Konstruktionssyntax in C# zu verschönern, sondern dient einem dedizierten Zweck.

Umso erfreulicher ist es, das ich mich mit meiner Meinung in bester Gesellschaft vorfinde. So erklärt z.B. Richard sehr gut, das es beim var Keyword nicht um die Verkürzung von Codezeilen geht sondern bei exzessivem Einsatz eher in die Kategorie Programmierfaulheit einzustufen ist. Ich persönlich befürworte vollständig seine Meinung, wonach var dort eingesetzt werden sollte, wo es benötigt wird, und nicht überall wo es möglich ist.

Setzt man var überall ein, wo es möglich wäre, kommt solcher Code zustande:

public object GetMatchingCode(object[] codes, string matchPattern, bool ignoreInvalid)
{
  var bestMatch = FindBestMatch(matchPattern);
  var blackList = codelists.GetBlackList(codes);

  foreach(var c = in blackList.GetConfirmedCodes())
  {
    var matchPoint = bestMatch.CompareCode(c, ignoreInvalid);
    matchPoint.Combine(c.ParentCode);
    if (matchPoint.IsUnique(bestMatch)) return matchPoint;
  }

  return null;
}

Du als Leser dieser Codezeilen hast kein Visual Studio und keine Intellisense. Weißt Du, worum es bei diesen Codezeilen eigentlich geht? Ich wüßte es jedenfalls nicht.

Zugegeben, das Beispiel mag überspitzt sein. Jedoch übertreibe ich nicht, wenn ich sage, das ich “echten” Code schon lesen (und verstehen) musste, der mindestens den gleichen Grad von “konsequentem var Einsatz” aufwies wie obiges Beispiel.

Auf der anderen Seite ist var natürlich auch notwendig und äußerst sinnvoll. Die Paradedisziplin dabei ist sicherlich LINQ:

var persons =
  from customer in db.Customers
  where customer.State = 1
  select new { Id = customer.Id, Name = customer.Name };

Ich für meinen Teil finde var und Typ-Inferenz eine gelungene, sogar notwendige Bereicherung in C# – aber nur dort, wo es wirklich gebraucht wird. Obwohl Soren in seinem Blog mit “the C# keyword var is evil” sicherlich übertreibt, ist es eine besonders empfehlenswert seinem Beispiel zu folgen und die geradezu unsinnige “Benutze immer var”-Funktion im ReSharper einfach abzuschalten.

Mein Fazit: var ist nur dann cool, wenn ich es wirklich brauche – ansonsten bleibe ich bei expliziter Typdeklaration und dem mächtigen Visual Studio Intellisense/Autocomplete.

Im Netz gibt es einige Code-Snippets und Parser, die Kommandozeilenparameter aufbereiten und das lästige interpretieren von Werten abnehmen. Bei der Suche nach eben so einem Parser bin ich auf NConsoler gestoßen, einem “Mini-Framework” für Konsolenanwendungen.

Das interessante an NConsoler ist der Ansatz der deklarativen Definition von Parametern und Operationen. Anstatt das Standard String-Array von Argumenten zu interpretieren, werden die möglichen Aktionen und Parameter einfach per Attribut definiert. Ein Vorteil dessen ist sicherlich der “Design by Contract”-Ansatz. Ein kleines Beispiel veranschaulicht die einfache Verwendung:

namespace ConsoleCalculator
{
	class Program
	{
		static void Main(string[] args)
		{
			Consolery.Run(typeof(Program), args);
		}

		[Action]
		public static void Add
			(
			[Required]
			int first, 

			[Required]
			int second, 

			[Optional(0)]
			int third
			)
		{
			Console.WriteLine("Result: {0}", first + second + third);
		}

		[Action]
		public static void Multiply
			(
			[Required]
			int first,

			[Required]
			int second,

			[Optional(1)]
			int third
			)
		{
			Console.WriteLine("Result: {0}", first * second * third);
		}
	}
}

Auf der Konsole sieht das Ergebnis dann foldendermaßen aus:

NConsoler-Anwendung in Aktion

Fazit: Ein nettes kleines Tool, mit dem man schnell Konsolenanwendungen mit Parameterübergabe entwickeln kann.

Symmetrie im Sinne von objekt-orientiertem Design kann in vielfältiger Weise auftreten. Ein prominentes Beispiel ist die Symmetrie über Schichten hinweg. Da beginnt man trivial mit einem UserAccountDTO und einem UserAccountDAO, bewegt sich dann auf den Business-Layer und erstellt eine UserAccount-Klasse um schlußendlich auf der Präsentationsschicht ein UserAccountController und UserAccountView zu erstellen. Diese Verfahrensweise “fördert” den “Symmetrie-Effekt”, ist aber nicht die einzige Ursache für Design-Symmetrien. Wie dem auch sei, im Ergebnis hat man ein geradezu perfekt symmetrisches Design des UserAccounts über alle Ebenen hinweg geschaffen (Anmerkung: Bei diesem Beispiel der “Layer-Symmetrie” spricht man auch öfter von “linearem Design”).

Auf den ersten Blick ist an so einer Symmetrie ja auch nicht viel auszusetzen: Alles ist ordenlich strukturiert, man findet sich zurecht und kann, mit Unterstützung der Symmetrie, schnell Abhängigkeiten des Systems oder von einzelnen Klassen finden. Dies ist augenscheinlich bei größeren Anwendungen ein Vorteil, denn ähnliche Strukturen und Verfahrensweisen erleichtern nunmal das Verständnis und die Wartung von großen Codeständen.

Jedoch ist Design-Symmetrie ein zweischneidiges und besonders scharfes Schwert. Es gibt einige Entwickler und sogar Architekten, die solche Symmetrien bedingungslos fordern und auf Teufel komm’ raus einzuhalten versuchen. Manche bewußt, manche sogar unbewußt, weil es “woanders ja auch so gemacht ist” oder “schnell von der Hand” geht.

Genau dort setzt sie ein, die Angst vor Asymmetrie. Denn es ist durchaus denkbar und überdies sinnvoll, sich für jedes Geschäftsobjekt oder -szenario Gedanken darüber zu machen, wie man es konzipiert. Dieser Entwurf kann und soll auch hinterfragen dürfen, ob vorhandene infrastrukturelle Systeme oder Konventionen dem gegebenen aktuellen Problem genügen oder nicht. Im Klartext: Konzeptionelle Symmetrie ist kein Zwang, sondern eine vorteilhafte Erscheinung, die aber im Allgemeinen bei Weitem nicht das Gewicht einer funktionalen Anforderung hat.

Um beim obigen Beispiel zu bleiben: Wäre ein “UserAccount” physisch auf der Datenbank auf mehrere Tabellen verteilt (z.B. Accounts, Users, UserSettings) und wäre demnächst z.B. eine User-Setting-Verwaltung angedacht, so wäre es sicherlich erwägenswert, statt mit einem JOIN über diese Tabellen einen UserAccountDAO zu erzwingen einfach drei DTO’s und DAO’s zu erstellen, die dann vom Businessobjekt (dem UserAccount) verwendet werden. Natürlich hängt so eine Entscheidung stark vom Kontext und den Anforderungen ab, aber ich hoffe, ich konnte mit dem Beispiel den Kerngedanken von “Symmetrie vs. Asymmetrie” etwas verdeutlichen.

Ich persönlich empfinde asymmetrische Designs (mit einigen Symmetrien oder Analogien) sogar “schöner”, zumal sie ein deutliches Indiz für starke Objektorientierung sind. In asymmetrischen Konzepten ist die Kohäsion zumeist deutlich stärker, die abstrakte Klassifikation der Objekte ist klar und die Vererbungshierarchien sind zuweilen kürzer. Im Endeffekt sind in meinen Augen solche asymmetrischen Muster in Software-Designs ein erster rudimentärer Ansatz hin zur Adaption von permakulturellem Denken in die Konzeption von Softwarearchitekturen und -systemen.

Mein Fazit: Keine Angst vor Asymmetrie! Auch asymmetrische Strukturen können schön und vor Allem nachhaltig effizient sein.

Es gibt viele verschiedene “Ängste”, denen man beim programmieren von OO-Software entgegnen kann. Diese Ängste lassen sich im Übrigen relativ gut aus dem Code “herauslesen”.

Eine der oftgesehendsten Ängste in der OO-Programmierung ist die Angst vor Logik. Im OO-Design spiegelt sich das relativ deutlich wider, wenn man viele verschiedene Klassen und Objekte hat, die sich um eine zusammenhängende Aufgabe, einen bestimmten Datensatz oder ein bestimmtes Objekt kümmern.

Ein Beispiel soll das Ganze etwas verdeutlichen:

public class Credentials
{
  private string username;
  private string password;

  public Credentials()
  {
  }

  public string UserName
  {
    get { return this.username; }
    set { this.username = value; }
  }

  public string Password
  {
    get { return this.password; }
    set { this.password = value; }
  }
}

Auf den ersten Blick mag man annehmen, die Klasse sei ein einfacher Datencontainer (DTO). Dem ist jedoch nicht so. In Wahrheit ist die Klasse eine Business Entity ohne Logik. Die Logik ist einfach in anderen Klassen, wie z.B. in solch einer:

public static class CredentialsUtility
{
  public static bool Validate(Credentials credentials)
  {
    if (credentials != null)
    {
      return !String.IsNullOrEmpty(credentials.UserName);
    }

    return false;
  }
}

An diesen zwei Klassen wird deutlich, das der Entwickler eine höllische Angst gehabt haben muss, das Business Entity mit Logik anzureichern. Denn i.d.R. ist es genau die Aufgabe eines Business Entities, diese Logik (z.B. Validierung) zu kapseln. Meiner Meinung nach ist diese “Angst” völlig unberechtigt und für ein kohärentes OO-Design kontraproduktiv. Fakt ist zudem, das es zur fundamentalen Schule der OO-Programmierung gehört, Klassen mit eindeutigen Verantwortlichkeiten zu schaffen.

Natürlich muss im Einzelfall geprüft werden, welcher Grad der Kohäsion für die Anwendung und die Architektur geeignet erscheint. Prinzipiell sollte man jedoch ein gutes Mittelmaß zwischen Kohäsion und Kopplung anstreben. Komponentenorientierung und lose Kopplung ist sicherlich wichtig. Auf der Ebene der Anwendungslogik respektive Business Entities sollte man meines Erachtens tunlichst zusammenhängende Logik in die Klasse zu kapseln.

Mein Fazit: Keine Angst vor Logik! Anwendungslogik gehört in die Anwendungsklassen und muss nur dann verteilt werden, wenn es wirklich notwendig ist.

Virtuelle Methoden sind eines der Kernkonzepte in der Objekt-orientierung, um Polymorphie zu ermöglichen. Das interessante an virtuellen Methoden ist ihre grundlegende Charakter-Eigenschaft, eine gewisse Aufruf- und Kontext-Konvention zu definieren, ohne das der Aufrufer der Methode die konkrete Implementierung oder besser das Verhalten der Methode hervorsehen kann.

Dieses Konzept in der Objekt-orientierung wurde im Laufe der Zeit stetig erweitert und verfeinert. So sind z.B. die abstrakten Methoden/Klassen sowie Interfaces eine Weiterentwicklung des Polymorphie-Gedankens von virtuellen Methoden. In C++ ist z.B. die Definition einer “puren” virtuellen Klasse (eine Klasse mit ausschließlich pur virtuellen Methoden) vergleichbar mit einem Interface in neueren Sprachen, wie z.B. C# oder Java.

Es ist folglich völlig nachvollziehbar, das der Einsatz von virtuellen Methoden in der objekt-orientierten Programmierung quasi unerläßlich ist, um bestimmte Konzepte umzusetzen. Nun ist es aber auch öfters der Fall, das die Zweckmäßigkeit des Einsatzes von virtuellen Methoden mißverstanden oder sogar mißbraucht wird. Des Öfteren begegne ich z.B. folgendem (oder ähnlichem) C#-Code:

public abstract class AnimalBase
{
  private Position pos;

  public virtual Position GetPosition()
  {
    return this.pos;
  }

  public virtual void Eat() {}

  public virtual void Run(Position newPos)
  {
    this.pos = newPos;
  }
}

Solche und ähnliche Klassen bekomme ich ab und an auf meinem Screen zu sehen, wenn ich durch Quellcodes von Software durchgehe. Manchmal sieht man sogar wahre “Orgien” von “protected virtual”, “protected internal virtual” oder sogar “public virtual”.

Es ist meiner Meinung nach offensichtlich, das der Programmierer der obigen Klasse die Zweckmäßigkeit einer virtuellen Methode nicht oder nur teilweise verstanden hat. Alle Methoden sind virtuell. Stellt man den Entwicklern solcher Klassen die Frage, warum alle Methoden virtualisiert wurden, bekommt man meistens folgende Antwort: “Die Klasse soll erweiterbar und spezialisierbar bleiben”.

Tatsächlich war es vor allem in den Anfangsjahren der Objekt-orientierung gang und gäbe, wirklich alle Methoden zu virtualisieren, um der Idealvorstellung der guten Erweiterbarkeit und Spezialisierung näher zu kommen. Vor allem “OO-Theoretiker” hatten in den Gründungsjahren gepredigt, das Konzept der virtuellen Methoden genügend auszuschöpfen. Vor dem Hintergrund dessen ist es z.B. auch nicht mehr so verwunderlich, das im Gegensatz zu C# bei Java alle Methoden standardmäßig virtuell sind.

Wenn dem so ist, das viele den massiven Einsatz von virtuellen Methoden bevorzugen, was ist dann daran so verkeht?

Das Problem von übereifrigem Einsatz virtueller Methoden versteckt sich gut, dementsprechend sind sie auch nicht so offensichtlich, jedoch nicht minder schwerwiegend: Das Verhalten – oder besser die “Stabilität” der Implementierung einer Klassenhierarchie ist nicht gewährleistet. D.h. stellt man eine Basisklasse mit sehr vielen virtuellen Methoden zur Verfügung, so kann das eigentlich gewünschte Verhalten der Basisklasse sowie deren Kindklassen nicht mehr vollends und sicher gewährleistet werden. Angewendet auf das obige Beispiel wird die Problemstellung etwas deutlicher:

public class Snake : AnimalBase
{
  private Position pos;

  public override void Run(Position newPos)
  {
    this.Creep(newPos);
  }

  public virtual void Creep(Position newPos)
  {
    while (!this.pos.Equals(newPos))
    {
      this.pos.X += Math.Sign(newPos.X);
      this.pos.Y += Math.Sign(newPos.Y);
      this.pos.Z += Math.Sign(newPos.Z);

      this.UpdateCreepState();
    }
  }

  protected virtual void UpdateCreepState()
  {
    /* some code */
  }
}

Auf den ersten Blick wirkt die Implementierung der “Snake”-Klasse plausibel. Dennoch führt die Implementierung zu einem massiven Fehler. Die “Standard-Implementierung” der GetPosition()-Methode von AnimalBase ist bei der Snake-Klasse nicht mehr operabel.

Bei einem so einfachen Beispiel mit wenigen Methoden ist das relativ offensichtlich – wäre aber die AnimalBase-Klasse eine komplexe Klasse (oder Klassen-Hierarchie) mit vielen virtuellen Methoden, so ist es selbst für geübte OO-Hasen nicht mehr überschaubar, welchen Einfluß man auf die Implementierung der Basisklassen ausübt, wenn man eine oder mehrere virtuelle Methoden überschreibt.

Für Eric Gunnerson, einer der C#-Gurus und C#-Program Manager (Microsoft), ist das oben gezeigte Problem das Hauptproblem exzessiver Verwendung virtueller Methoden. Für ihn ist der massive Einsatz von virtuellen Methoden einer der 7 Todsünden in der OO-Programmierung.

Mittlerweile sind sogar einige “OO-Theoretiker” davon überzeugt, dass der massive bzw. ausschließliche Einsatz von virtuellen Methoden wirklich keine gute Idee ist. Das liegt vor allem daran, das sich in der Praxis herausgestellt hat, das vor allem bei großen Software-Projekten durch die “Freiheit des Überschreibens von virtuellen Methoden” das Liskov-Substitutions-Prinzip stark gefährdet bzw. zum Teil durchbrochen wird.

Zu dieser Problemstellung drückt sich auch Anders Hejlsberg, leitender Architekt und Miterfinder der Programmiersprache von C# (Microsoft), besonders deutlich aus. In einem Interview über die C#-Design-Konzepte geht er indirekt auf die Probleme der Stabilität, der Gefährung des vereinbarten Verhaltens (”Incoming and outgoing contracts”) und Versionierungsproblemen durch virtuelle Methoden ein. Seiner Meinung nach ist durch generellen oder exzessiven Einsatz virtueller Methoden (wie z.B. in Java) die Gefahr wesentlich größer, das o.g. Probleme auftreten.

Ein Zitat von Anders Hejlsberg trifft meiner Meinung nach den Nagel auf den Kopf:

There are two schools of thought about virtual methods. The academic school of thought says, “Everything should be virtual, because I might want to override it someday.” The pragmatic school of thought, which comes from building real applications that run in the real world, says, “We’ve got to be real careful about what we make virtual.”

Ich persönlich schließe mich der Schule des “Lasst uns virtual nur dann verwenden, wenn es wirklich notwendig ist” an. Es ist vollkommen klar, das eine virtuelle Methode ein wichtiges Werkzeug für gutes OO-Design ist. Das wird alleine schon dadurch deutlich, das sie öfter zum Einsatz kommt, wenn man essentielle Design Patterns wie z.B. Template Method, Composite, Decorator oder Visitor (um nur einige zu nennen) implementiert.

Jedoch ist es meiner Meinung nach besonders wichtig zu erkennen, dass man virtuelle Methoden wirklich nur dann einsetzt, wenn es notwendig bzw. sinnvoll ist. Eine pauschale Deklaration einer virtuellen Methode mit der Begründung der Erweiterbarkeit ist unüberlegt und in den meisten Fällen nicht sinnvoll. Folgerichtig ist in meinen Augen jeder Entwickler mit Sicherheit gut beraten, die Microsoft Guidelines zum Einsatz virtueller Methoden zu beachten.

Denn die WCF – und das ist ja nichts neues – ist extrem flexibel und erweiterbar. Interessant wird es allerdings erst, wenn diese Flexibilität und Erweiterbarkeit in der Praxis effektiv eingesetzt werden kann.

Mit Hilfe von WCF Custom Behavior Extensions kann man elegant eigene Behaviors dem WCF Kommunikationsstrom hinzufügen und somit effizient vertikale Funktionalität wie z.B. Validierung oder Restriktion implementieren.

Zum Artikel habe ich auch noch ein paar Code Samples zum Download bereitgestellt.

Für mich persönlich kann ich einen sehr positiven Eindruck von der Veranstaltung feststellen, zumal ich denke dass doch einige Teilnehmer nach dem Vortrag ein paar neue Erkenntnisse für sich mitnehmen konnten. Die angenehme und wissensdurstige Atmosphäre hat sicherlich seinen Beitrag für dazu geleistet, das ich meine Aufgabe als Referent mit einem gewissen Spaßfaktor erfüllen konnte.

Für all diejenigen, die nicht an der Veranstaltung teilehmen konnten oder die Teilnehmer, die gerne dass ganze nochmal nachlesen möchten habe ich im Works-Bereich einen Artikel bereitgestellt, in der die Kernthemen des Vortrages festgehalten sind. Dort stehen übrigens auch die Präsentation selbst sowie die gezeigten Code-Samples zum Download bereit.

Ich bin wie immer gespannt auf Feedback & Kommentare. Viel Spaß mit den Web Services Grundlagen.

Viel Spaß bei Spiel und Analyse des Codes!

Völlig parteilos – ich kenne beide Entwickler :-) – möchte ich diese zwei Design-Konzepte ein wenig aus meiner eigenen Betrachtungsweise durchleuchten. Auf gut englisch – my 2c…

Zunächst sollte man sich meiner Meinung nach der Natur des Web Services im Klaren sein. Konkret ist ein Web Service eine öffentliche Schnittstelle zum Aufruf einer entfernten Operation. Nun ist soetwas ja nicht das 8. Weltwunder – will heissen dass es viele weitere, zum Teil deutlich ältere Technologien gibt, die das gleiche bezwecken wollen – es seien hier nur RPC und CGI als prominente Beispiele erwähnt. Das Problem “stateful” vs. “stateless” stellt sich also nicht erst seit dem es Web Services gibt.

Einen entfernten Aufruf – den berüchtigten “Remote Call” durchzuführen ist mit der Web Services-Technologie mittlerweile kinderleicht. Remote operations zur Verfügung zu stellen ist mit dem .NET Framework zum Beispiel fast genauso kinderleicht. Umso mehr sind Entwickler dazu geneigt, diese Leichtigkeit der Verwendung mit “Leichtsinnigkeit” zu verwechseln. Denn die Tragweite der Entscheidungen über ein Web Service Design kann manchmal ungeahnte Züge annehmen.

Doch zurück zum Thema: Grundsätzlich wurden Web Services für den automatisierten (also maschinellen) Informationsaustausch geschaffen. Per Definition des W3C ist ein Web Service nämlich folgendes:

A Web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAPmessages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards.

So. Eine klare Ansage. Aber beim zweiten durchlesen wird auch schon deutlich, wo der eigentliche Knackpunkt liegt. Es geht um das Teilstück “…interoperable machine-to-machine interaction…”. De facto lässt sich daraus ableiten, dass in der Idealform jeder Rechner innerhalb eines Netzwerkes jeden Dienst und dessen Operationen ansprechen und verarbeiten kann. Das kann auch komplexere Szenarien unterstützen; z.B dass Rechner, die Dienste zur Verfügung stellen, ihrerseits zur Erfüllung ihres eigenen Dienstes einen oder mehrere andere Dienste in Anspruch nehmen. Weiterhin ist per Definition auch die Multiplizität eines Dienstes freigestellt – d.h. es kann einen oder mehrere gleichartige, oder sogar equivalent operierende Dienste geben, die auf einer oder mehreren Rechnern zur Verfügung gestellt werden.

Bevor es nun zu theoretisch wird, kann man die Gedankenspiele abkürzend auf einen Nenner bringen: Bei Web Services geht es um flexible Kommunikation. Die Operation wird demjenigen zur Verfügung gestellt, der Sie braucht und ist idealerweise jederzeit ersetzbar. Des Weiteren ist die Operation idealerweise kontextunabhängig – lässt sich also ohne weiteres im Verbund mit anderen Operationen aufrufen, um daraus eine neue, sog. “orchestrierte” Operation zu formen.

Ich laufe hier natürlich sehr in Gefahr, in das SOA-Thema auszuschweifen – also gleich weiter mit der Ableitung der Definition des Web Services zu Entscheidungshilfen beim Design von Web Services.

Jetzt, da man die “Natur” eines Web Services sich genauer vor Augen hält, lässt sich eindeutig sagen, dass Web Services per se kontextunabhängig sind – im Resultat also “stateless”. Der Begriff “stateless” ist hier sehr leicht mit “statisch” ersetzbar – soll es aber nicht sein. Ein Web Service ist nicht zwingend statisch, weil es keinen Zustand hat. Der Gedanke der Kontextunabhängigkeit manifestiert sich bei Web Services nahezu überall: Die SOAP-Spezifikation enthält z.B. zahlreiche Möglichkeiten, Meta-Daten mit den Daten zu einer Operation zu übertragen. Im .NET Framework wird standardmäßig bei jedem Web-Service-Methoden-Aufruf die Web-Service-Klasse selbst instanziiert – eindeutige Zeichen dafür, dass Web Services für kontextunabhängige Verwendung ausgelegt worden sind.

Ergo: Web Services sind erst mal von Haus aus “stateless”. Aber wieso spielen nun viele Entwickler mit dem Gedanken, einen Web Service “stateful” werden zu lassen? Das kann viele Unterschiedliche Gründe haben – in dem von mir geschilderten Fall war die Datenmenge der Vater des Gedanken. Es sei hier nur kurz in groben Zügen der Werdegang der Idee zum “stateful” Web Service beschrieben:

Zur Implementierung einer Suche frägt der Client mit variablen Parametern ein Satz von Daten an – die resultierende Datenmenge ist unglaublich groß (sagen wir mal mehrere tausend Datensätze mit einer großen Menge an Daten, sagen wir mal 1MB pro Datensatz). Die Abfrage und Beschaffung der Daten auf der Datenbank kostet sehr viel Zeit (sagen wir mal mehrere Minuten) und kostet unglaublich viel Ressourcen (sagen wir mal es ist eine alte, gebrechliche Datenbank mit wenig Skalierbarkeit). (Merkt man, dass ich nicht gut im Erfinden von Anforderungen bin?)

Um nun Ressourcen zu schonen und die Geschwindigkeit zu erhöhen, kann man eine Session einführen, die bei der initialen Such-Abfrage erstellt wird. Die Abfrage wird gegen die Datenbank ausgeführt, das Ergebnis in der Session gespeichert und nur ein Teil der Daten (sagen wir mal, die ersten hundert) an den Client zurückgeliefert. Sollte der Client in einem zweiten Aufruf mehr Datensätze verlangen, werden die in der Session gespeicherten Daten zurückgeliefert, anstelle eine neue Abfrage gegen die Datenbank abzusetzen.

Ich möchte an dieser Stelle den aufmerksamen Leser bitten, über die Sinnhaftigkeit dieser Idee – wie ich es getan habe – hinwegzusehen und sich nur auf die Thematik der Kontextbezogenheit zu konzentrieren – Danke.

Nun, in Konsequenz würde die Einführung einer Session folgende Auswirkungen haben:
Die Session müsste erstellt werden, ein Session-State-Service müsste die Sessions verwalten. Wie es mit Sessions so ist, wäre die Session nur begrenzt gültig – und damit auch der gewünschte Effekt in begrenztem Maße erreicht. Weiterhin müsste die Session-ID in jedem Aufruf mit übergeben werden – das Interface würde also mit noch mehr Meta-Daten beladen werden. Im Übrigen wäre der Aufruf der zweiten Operation (”gebe mir noch mehr Datensätze”) nur möglich, wenn zuvor die erste aufgerufen wurde.

All diese meiner Meinung nach unvorteilhafen Konsequenzen müsste man in Kauf nehmen, um das gewünschte Ziel zu erreichen. Ein ziemlich teurer Preis wie ich finde.

Mit zustandsbehafteten Web Services schafft man sich aus meiner Sicht den Flaschenhals “Session-Manager” an, erhöht u.U. die “Chattiness” der Kommunikation zwischen Client und Server und schreibt dem Client auch noch Regeln vor, wie er welche Operationen aufzurufen hat, damit er an das gewünschte Ergebnis kommt. Stellt man sich dieses Szenario auch noch in einer Umgebung vor, die für hohe Performance und Verfügbarkeit ausgelegt ist (z.B. im Cluster), kommen noch kleinere Hürden wie Persistierung der Sessions und Web Service Paralellität hinzu.

Alles in allem ist meiner Meinung nach – zumindest für das oben genannte Szenario – ein zustandsbehafteter Web Service
1. schwieriger zu implementieren
2. keine signifikante Alternative zur Steigerung des Datendurchsatzes
3. mit vielen Hürden bespickt (Session-Manager, Multi-Threading)
4. wesentlich schwerer skalierbar
5. für Clients um ein vielfaches komplexer in der Verwendung

Sofern es also nicht wirklich sehr gute Gründe für die Kontextbezogenheit bestimmter Web Service-Methoden gibt, gilt beim Design von Web Services für mein Dafürhalten die grundlegende Orientierung nach der eigentlichen technologischen Ausrichtung des Web Services – stateless.

Die Motivation für diesen Artikel habe ich dennoch relativ schnell gefunden. Nachdem ich vor einiger Zeit das Pattern für den Einsatz in einer Anwendung propagiert hatte, sah ich mich bestürzten Kommentaren ausgesetzt: “Wie kannst Du nur? Wer setzt denn heutzutage noch Singleton ein? Das ist doch das Anti-Pattern schlechthin…”

Schnell hatte ich begriffen, dass meinem gegenüber wohl der Sinn und Zweck des Singleton nicht ganz geläufig war. Nach einigen Minuten war die Sache schnell geklärt. Trotzdem hatte es mich überrascht, wie viele Entwickler doch einen verzerrten Eindruck des Entwurfsmusters haben.

Lange Rede, kurzer Sinn: Yet another Singleton Pattern Article. In vorest 3 Teilen versuche ich meine Sicht der Vor- und Nachteile des Patterns zu transportieren. Es war mir irgendwie auch ein Bedürfnis, zumindest die Basics des Patterns mal festzuhalten – es kommt leider noch oft genug vor, dass man bei Code-Reviews sich noch über solche Themen ernsthaft unterhalten muss.

Falls also trotz der Unmengen an Informationen darüber jetzt Dein Interesse geweckt worden ist: Einfach Singleton-Pattern im Einsatz lesen!