Der russische Schriftsteller Isaac Asimov hat neben zahlreichen Werken, die primär der Science-Fiction angehören, auch zahlreiche Kurzgeschichten geschrieben: Dazu gehört unter anderem eine kriminalistische Kurzgeschichte mit dem Titel What’s in a Name?, in der es um die Aufklärung eines Mordes geht.

Den Titel What’s in a Name? könnte man im Deutschen sinngemäß am Besten mit der Frage wiedergeben, welche Bedeutung einem Namen innewohnt – und ob einem Namen überhaupt eine Bedeutung innewohnt.

Angelehnt an diese Semantik möchte ich heute die Frage stellen, welche Bedeutung einer Schnittstelle innewohnt. Ausgangslage für diese Frage ist eine Diskussion, die ich vor einigen Tagen mit Peter Bucher geführt habe.

Thema dieser Diskussion war ursächlich, inwiefern LightCore benannte Registrierungen von Typen unterstützen soll. Nahezu allen Microkerneln liegt das Prinzip zu Grunde, einen konkreten Typ auf eine abstrakte Schnittstelle zu registrieren, über die er dann instanziiert werden kann.

Zur Instanziierung bieten die meisten Microkernel zwei Varianten an: Entweder wird die einzig vorhandene Registrierung genutzt, um eine Instanz des konkreten Typs zu erzeugen, oder – im Fall mehrerer vorliegender Registrierung – wird von jedem Typ eine Instanz erzeugt und eine entsprechende Liste zurückgegeben.

In LightCore geschieht dies mit Hilfe der Methoden Resolve<T> und ResolveAll<T>, die eine einzelne Instanz des Typs T oder ein IEnumerable<T> zurückgeben – je nachdem, wie viele Registrierungen für den angeforderten Kontrakt vorliegen.

So weit, so gut. Nun bieten die meisten Microkernel – so derzeit auch LightCore – allerdings zusätzlich noch die Möglichkeit, im Falle mehrerer Registrierungen diese an Hand von Namen zu unterscheiden. Auf diese Art können beispielsweise mehrere Addins auf die Schnittstelle IAddIn registriert werden, dennoch kann die verwendende Anwendung gezielt die Instanz eines dedizierten Addins anfragen.

Ich persönlich konnte mich mit diesem Vorgehen noch nie anfreunden – und auch heute noch halte ich es für falsch. In unserer Diskussion ging es nun darum, die Beweggründe für meine Abneigung gegenüber benannten Registrierungen herauszufinden.

Peter hat mir als konkrete Diskussionsgrundlage die Schnittstelle IController aus dem Namensraum System.Web.Mvc in ASP.NET MVC genannt, die von jedem Controller implementiert wird. Wird nun in einer ASP.NET MVC-basierten Anwendung auf einen Microkernel gesetzt, um die einzelnen Controller zu instanziieren, so ist klar, dass alle Controller auf die gleiche Schnittstelle registriert werden.

Sobald eine Anfrage an eine solche Webanwendung gestellt wird, besteht die Aufgabe nun darin, den richtigen Controller zu instanziieren: Die Auswahl allein an Hand der Schnittstelle zu treffen, funktioniert nicht – hierüber lassen sich die einzelnen Controller nicht unterscheiden. Ein Aufruf von ResolveAll<IController> nützt aber auch nichts, da auf diese Art alle Controller instanziiert werden würden.

Die vermeintliche Lösung liegt nun darin, jede Registrierung eines Controllers mit einem Namen auszustatten, und vom Microkernel sodann eine benannte Instanz anzufordern. Dass dieses Vorgehen funktioniert, steht außer Frage – doch ist es sinnvoll? Ich meine, nein. Denn es widerspricht dem Sinn einer Schnittstelle.

Die Idee einer Schnittstelle ist, verschiedene Implementierungen eines Aspekts zu ermöglichen, die potenziell gegeneinander austauschbar sind: Eine Schnittstelle dient also dazu, nach außen gleiches Verhalten anzubieten, aber mit verschiedenen Implementierungen – wobei die konkret gewählte Implementierung für den Verwender transparent ist.

In anderen Worten: Angenommen, es liegen eine Schnittstelle IDataSource sowie zwei Implementierungen, SqlServerDataSource und XmlDataSource, vor. Dann ist es für die Anwendung, die auf IDataSource aufsetzt, irrelevant, welche konkrete Implementierung konfiguriert wurde – denn das Verhalten der Implementierungen nach außen ist gleich, nur die Implementierung unterscheidet sich.

Dieses Muster dient als Basis für austauschbare Komponenten: Austauschbarkeit gelingt nur, wenn neben der Syntax auch die Semantik gleich bleibt – lediglich die Umsetzung darf schwanken.

Auf das Beispiel der Controller in ASP.NET MVC bezogen trifft dieses Muster aber nicht zu – denn die Syntax der einzelnen Controller ist zwar identisch, die Semantik aber nicht. Denn beispielsweise ein HomeController verhält sich schlicht und ergreifend anders als ein DownloadController, obwohl beide durchaus die Schnittstelle IController implementieren.

Der Sinn der beiden Controller beziehungsweise ihre Existenzberechtigung sind verschiedener Natur, sie erfüllen verschiedene Aufgaben und sind auch nicht gegen einander austauschbar. Zwei Implementierungen eines HomeControllers wären austauschbar – aber nicht ein Home- und ein DownloadController.

Bei den Controllern gilt also das genaue Gegenteil von oben genanntem Paradigma: Hier wird nicht gleiches Verhalten auf unterschiedliche Art implementiert, statt dessen wird unterschiedliches Verhalten auf die gleiche Art implementiert! Das ist ein gravierender Unterschied in Bezug auf die Semantik. Dass die Syntax bei all dem gleich bleibt, ist lediglich ein Nebeneffekt – der aber für die Komponentenorientierung an dieser Stelle nichts zur Sache tut.

Kurzum: Es ist schlicht und ergreifend falsch, zwei unterschiedliche Typen von Controllern auf die gleiche Schnittstelle zu registrieren. Wenn man diese Tatsache erst einmal akzeptiert hat, wird auch schnell deutlich, was genau sich an benannten Registrierungen falsch anfühlt: Sie sind keine Lösung, sie sind lediglich ein Workaround für ein tiefer liegendes Problem.

Die Frage lautet nun – was wäre eine korrekte Lösung, die sich nicht im Nachhinein als halbherziger Workaround entpuppt?

Eine Möglichkeit wäre, zwischen die Schnittstelle IController und die jeweils konkreten Implementierungen eine weitere Schnittstelle einzuziehen – wie IHomeController oder IDownloadController. Diese wären geeignet, eine semantische Unterscheidung zwischen den einzelnen Controllern zu begründen, würden benannte Registrierungen überflüssig machen, bei all dem aber die gemeinsame Syntax auf Grund der gemeinsamen Basis IController erhalten.

Abgesehen von der dadurch fehlenden Notwendigkeit für benannte Registrierungen hätte diese Variante zum anderen den Vorteil der echten Austauschbarkeit: Da nun auf eine semantisch korrekt definierte Schnittstelle registriert wird, könnten auch verschiedene Implementierungen beispielsweise des HomeControllers problemlos gegeneinander ausgetauscht werden.

Letztlich wage ich die Behauptung aufzustellen, dass bereits die Existenz benannter Registrierungen in Microkerneln ein Fehler ist – denn entweder ist es tatsächlich sinnvoll, verschiedene gleichwertige konkrete Typen auf die gleiche Schnittstelle zu registrieren – dann sollten diese aber auch als gleichwertig behandelt werden – oder eben nicht. Ein Mischmasch aus beidem ergibt keinen Sinn.

Sofern die Einführung zwischengeschalteter Schnittstellen nicht möglich ist, gibt es darüber hinaus immer noch die Möglichkeit, einzelne Typen mit einem entsprechenden Attribut oder einer Markerschnittstelle auszustatten – um diese dann nach dem Laden durch den Microkernel eindeutig identifizieren zu können.

Abschließend lautet mein Plädoyer daher, dass die Fähigkeit, benannte Registrierungen durchzuführen, kein Feature eines Microkernels ist, sondern ein Bug – der enthalten ist, weil alle anderen es ebenso machen. Wünschenswert wäre aus meiner Sicht, die Unterstützung für benannte Registrierungen zu entfernen und statt dessen auf ein sauberes Verfahren zu wechseln – einige Ansätze hierfür habe ich genannt.

Gestern Abend war ich bei der .NET Usergroup Konstanz-Kreuzlingen bereits zum zweiten Mal zu Gast – das erste Treffen in neuen Räumlichkeiten, das zudem von einem – zumindest teilweise – neuen Team organisiert wurde.

Als Thema des Abends hatten wir im Vorfeld

.NET 4 und Visual Studio 2010

ausgewählt- also das gleiche Thema wie bei meinem Besuch bei der .NET Usergroup Nordwestschweiz vor rund einer Woche. Auch gestern habe ich deshalb die aus meiner Sicht wichtigsten Aspekte herausgegriffen und in einem kompakten, aber detaillierten Überblick zusammengefasst:

• Visual Studio 2010 als Editor
• Visual Studio 2010 als Plattform
• CLR 4.0
• Visual C# 4.0
• Visual F#
• Parallelprogrammierung
• Managed Extensibility Framework
• Historical Debugging

Auch gestern bin ich neben der reinen Vorstellung dieser Aspekte auch auf potenzielle Nachteile eingegangen, insbesondere C# 4.0 bietet doch Anlass für einige Kritikpunkte.

Eingebettet in all dies habe ich auch zahlreiche Detailverbesserungen angesprochen – von Verbesserungen in der grafischen Oberfläche von Visual Studio bis hin zu verbesserten Best Practices.

Auch eine kurze Präsentation meines derzeit favorisierten Werkzeugs .NET Reflector Pro durfte zu Anfang nicht fehlen.

Im Anschluss an den rund 90-minütigen Vortrag gab es noch interessante Gespräche, so dass mir auch der gestrige Abend wieder sehr viel Spaß gemacht hat – und den Teilnehmern augenscheinlich ebenfalls.

Die Planung für die nächsten Treffen der .NET Usergroup Konstanz-Kreuzlingen ist zwar bereits in trockenen Tüchern, aber ich bin mir dennoch sehr sicher, dass es nicht mein letzter Besuch bei dieser Usergroup war.

Im August 2009 habe ich Accuracy als Charakteristik für einen guten Entwickler gefordert.

Im Wesentlichen habe ich mich bei der Definition des Begriffs von dem Computerspiel Quake III Arena leiten lassen, in dem Accuracy für eine überdurchschnittlich hohe Treffgenauigkeit steht. Auf dieser Basis und übertragen auf die Softwareentwicklung habe ich Accuracy damals als

Die Liebe für Details, und die Fähigkeit, auch auf jeden Punkt und jedes Komma zu achten – und nicht nur oberflächlich mal eben schnell über Code hinweg zu gehen.

definiert. Nachdem ich diese Begriffsdefinition inzwischen eine Weile verwende, ist mir bewusst geworden, dass Accuracy alleine nicht genügt, sondern noch ein weiteres Maß erforderlich ist, um die Arbeitsweise eines Entwickler bewerten zu können: Präzision.

Auch – zumindest die englischsprachige – Wikipedia trennt zwischen Accuracy und Präzision, wobei dort wiederum die Analogie zur Waffenkunde aufgegriffen wird:

• Accuracy bezeichnet die Treffgenauigkeit, wie weit Treffer also vom gewünschten Ziel abweichen.
• Präzision hingegen bezeichnet die Wiederholbarkeit, wie groß die Varianz der Treffer also ist.

Natürlich sind beide Werte unabhängig voneinander, denn sie lassen sich in jeder beliebigen Ausprägung miteinander kombinieren – weder erfordert eine hohe Accuracy eine hohe Präzision, noch gilt dies umgekehrt.

Was bedeuten diese beiden Begriffe nun übertragen auf die Softwareentwicklung?

Accuracy bedeutet für mich, dass ein Entwickler der idealen Form von Quellcode nahe kommt, das heißt, akkurat geschriebener Code zeichnet sich durch die Abwesenheit von Formfehlern aus. Als Merkmale für derartigen Code können beispielsweise

• die korrekte Einrückung sowie der korrekte Gebrauch von Leerzeilen,
• die korrekte Klammerung,
• die korrekte Schreibweise von Bezeichnern
• und korrekte Rechtschreibung und Grammatik in Kommentaren

dienen. Entwicklern, die in der Lage sind, solchen Code zu erzeugen, kann man daher durchaus eine hohe Treffgenaugkeit zugestehen.

Nun stellt sich zusätzlich die Frage nach der Präzision. Dass Fehler vorkommen, kann kaum verhindert werden – die Frage ist aber, wie breit gestreut die Varianz der Arten von Fehlern ist.

Wird beispielsweise korrekt eingerückt, korrekt geklammert und es finden sich lediglich ab und an Kommafehler in Kommentaren, so kann man durchaus eine hohe Präzision zugestehen. Umgekehrt gilt – wenn die Arten von Fehlern weit gestreut sind, verfügt ein Entwickler über eine nur niedrig ausgepägte Präzision – wobei er dennoch, wenn er nur wenige Fehler macht, eine hohe Accuracy aufweisen kann.

Ich glaube, dass diese Trennung in Accuracy und Präzision wichtig ist, um die Qualität von Code und damit auch die Fähigkeiten des entsprechenden Entwicklers angemessen beurteilen zu können.

Natürlich beziehen sich beide Werte nicht nur auf die formale Gestalt von Code, sondern beispielsweise auch auf das Durchdenken dessen, was eigentlich codiert wird – auch hier können Ergebnisse mit beiden Maßen gemeinsam besser beurteilt werden als nur mit einem.

Es war einmal … mit diesen Worten beginnen üblicherweise Märchen – und genau darum handelt es sich bei dem Buch Geschichten vom Scrum von Holger Koschek, das am 1. November 2009 im dpunkt Verlag erschienen ist.

In einem weit entfernten Königreich lebten die Menschen mit sich und der Natur im Einklang. Sie betrieben Ackerbau und Viehzucht, waren in der Lage, sich selbst zu versorgen – und im Grunde wären sie glücklich und zufrieden gewesen, wenn ihre Lebensgrundlage nicht immer wieder Drachen zum Opfer gefallen wäre.

Zwar gab es Drachenfallen, doch die Drachen lernten schnell, so dass es ihnen immer wieder gelang, sich aus den Fallen zu befreien. Im Grunde herrschte ein beständiges Wettrüsten zwischen den Drachenbauern und den Drachen.

Eines Tages hatte der König genug von diesem ewigen Wettlauf und beschloss, ein Team zusammenzustellen, das die ultimative Drachenfalle bauen sollte: Da jedoch alle Drachenfallenbaumeister unentbehrlich waren, blieb dem König letztlich nichts anderes übrig, als ein zusammengewürfeltes Team zu akzeptieren.

Die ultimative Drachenfalle sollte gebaut werden von dem Aschenputtel, der Hexe, dem Großväterchen, dem Ritter und dem königlichen Schlossgespenst – unter Anführung des Prinzen.

Da nicht alle Anforderungen an eine solche Falle bekannt waren, wurde beschlossen, die Falle agil zu entwickeln – nach Scrum.

Unter diesen Voraussetzungen nimmt das Märchen seinen Lauf, und Holger Koschek schildert in einer wunderschönen Erzählweise, wie die einzelnen Personen nach und nach zu einem Team zusammenwachsen, auf welche Probleme sie dabei stoßen, wie sie Scrum umsetzen, …

Als Leser begleitet man das Team auf dieser Reise und fiebert mit, ob es ihnen gelingen wird, die hoch gesteckten Ziele zu erreichen, und welche Windungen die Geschichte dabei nehmen wird.

Insgesamt handelt es sich bei Geschichten vom Scrum um ein sehr ungewöhnliches, aber äußerst gelungenes Buch. Es gehört damit in die Reihe der wenigen Fachbücher, in denen nicht nur die fachliche Materie vermittelt wird, sondern deren Lektüre auch schlichtweg Spaß macht.

Wer sich für Scrum im Speziellen und agile Methoden im Allgemeinen interessiert, sollte auf jeden Fall einen längeren Blick in dieses Buch werfen.

Am heutigen Abend fand das initiale Treffen der .NET Usergroup Nordwestschweiz in Basel in den Räumen der YooApplications AG statt – und ich hatte die Ehre, von den beiden Veranstaltern Laurin Stoll und David Richter als Referent eingeladen worden zu sein.

Als Thema des Abends hatten wir im Vorfeld

.NET 4 und Visual Studio 2010

ausgewählt. Auf Grund der Vielzahl an Neuerungen habe ich deshalb die aus meiner Sicht wichtigsten Aspekte herausgegriffen und in einem kompakten, aber detaillierten Überblick zusammengefasst:

• Visual Studio 2010 als Editor
• Visual Studio 2010 als Plattform
• CLR 4.0
• Visual C# 4.0
• Visual F#
• Parallelprogrammierung
• Managed Extensibility Framework
• Historical Debugging
• Code Contracts

Neben der reinen Vorstellung bin ich dabei auch auf potenzielle Nachteile eingegangen, quasi ein wenig abseits der Hochglanzfolien. Außerdem habe ich viele Kleinigkeiten und Detailverbesserungen angesprochen – von Verbesserungen in der grafischen Oberfläche von Visual Studio bis hin zu verbesserten Best Practices.

Auch eine kurze Präsentation meines derzeit favorisierten Werkzeugs .NET Reflector Pro durfte zu Anfang nicht fehlen.

Im Anschluss an den rund 90-minütigen Vortrag haben sich mit den Teilnehmern noch zahlreiche interessante Gespräche ergeben, so dass mir der Abend ausgesprochen viel Spaß gemacht hat, und ich mich schon sehr auf das nächste Mal freue.

Danken möchte ich den beiden Veranstaltern dabei nicht nur für die Einladung, sondern auch für die viele Mühe, die sie sich gemacht haben: Man merkt ihnen an, dass sie sehr motiviert sind und ihnen das Thema Community sehr am Herzen liegt.

Insgesamt bleibt mir damit nur noch, der .NET Usergroup Nordwestschweiz viel Erfolg für die Zukunft zu wünschen!

Am 13. Oktober 2008 haben Peter Bucher und ich unter dem Titel Noch Fragen, Bucher? Ja, Roden! angekündigt, jeweils zum ersten eines jeden Monats einen Kommentar zu einem vorab gemeinsam gewählten Thema verfassen zu wollen. Bisher sind in dieser Reihe folgende Kommentare erschienen:

• 1. Februar 2010: Felder vs Eigenschaften
• 1. Januar 2010: this oder kein this?
• 1. Dezember 2009: Reflection – Fluch oder Segen?
• 1. November 2009: Wie viel Sinn machen Unittests?
• 1. Oktober 2009: Vererben oder aggregieren?
• 1. September 2009: Alles var – oder nicht?
• 1. August 2009: C# oder VB: Welche Sprache soll ich lernen?
• 1. Juli 2009: Primärschlüssel: GUID vs Identity
• 1. Juni 2009: Heißt die Zukunft RIA?
• 1. Mai 2009: Woran erkennt man einen guten Entwickler?
• 1. April 2009: Interfaces vs abstrakte Basisklassen
• 1. März 2009: Sinn und Zweck von AOP
• 1. Februar 2009: Die Forderung nach Softwarequalität
• 1. Januar 2009: SOA vs WOA
• 1. Dezember 2008: Dynamic Language Runtime: .NET, quo vadis?

Heute, am 1. März 2010, ist es nun wieder so weit, und unser Thema für diesen Monat lautet:

Abstraktion

So wohl Peter wie auch ich haben uns unabhängig voneinander im Vorfeld unsere Gedanken gemacht, wie wir diesem Thema gegenüberstehen. Außerdem nimmt diesen Monat auch Roberto Bez an unserem Streitgespräch teil.

Peters und Robertos Kommentare finden sich zeitgleich in den entsprechenden Blogs, folgend nun mein Kommentar zu diesem Thema:

Das Selbstverständnis der Informatik, anderen Fachgebieten eine Hilfswissenschaft zu sein, impliziert die Anwendung von Abstraktion bereits: Letztlich werden deren Objekte, Daten und Prozesse nämlich in geeinete informationstechnische Strukturen abstrahiert.

Abstraktion an sich wird dabei beispielsweise von Wikipedia als

induktiven Denkprozess des Weglassens von Einzelheiten und des Überführens auf etwas Allgemeineres oder Einfacheres

definiert. Es geht also letztlich darum, gegebene Probleme besser lösen zu können, indem für die Lösung unnötige Komplexität verringert wird – in der Regel, indem diese durch eine einfachere Darstellung verborgen wird.

Bereits im schulischen Mathematikunterricht findet Abstraktion in dieser Form statt, wenn beispielsweise die Lösung von Textaufgaben gefordert wird, die die eigentliche mathematische und abstrakte Aufgabe in einer mehr oder weniger anschaulichen Beschreibung verpacken.

Ohne Abstraktion wäre die Lösung mancher Aufgaben nicht nur bedeutend schwieriger und komplexer oder gar unmöglich, ohne sie wäre auch die Kommunikation mit anderen Disziplinen bedeutend erschwert.

Für einen Informatiker spielt es in der Regel nämlich zunächst keine Rolle, ob zum Beispiel Gepäckstücke an einem Flughafen oder aber Reagenzgläser in einem medizinischen Labor automatisiert befördert und verarbeitet werden sollen – beide Aufgaben können zu einem Logistikproblem abstrahiert werden, das mit entsprechenden Verfahren lösbar oder zumindest annäherbar ist.

Abstraktion nimmt also eine essenzielle Rolle in der Informatik ein – doch Abstraktion ist nicht per se als positiv zu bewerten. Abstraktionen verbergen nämlich nicht nur unnötige Komplexität, sondern neigen bewusst oder unbewusst auch dazu, Details zu verbergen, die für die Lösungsfindung allerdings relevant sind.

Joel Spolsky bezeichnet diesen Umstand als The Law of Leaky Abstractions. Er fasst seine Erkenntnisse bezüglich Abstraktion in dem Satz

All non-trivial abstractions, to some degree, are leaky.

zusammen, was letztlich so viel bedeutet, dass Abstraktionen nicht nur dabei helfen, Probleme zu lösen, sondern ihrerseits lecken und neue Probleme verursachen, weil die notwendigen Details nicht mehr bekannt sind – ironischerweise desto eher, je stärker abstrahiert wird.

Beispiele für Abstraktionen und die dazugehörigen Lecks sind – wie in der gesamten übrigen Entwicklung von Software – auch in .NET ohne weiteres zu finden:

So abstrahiert die Garbage Collection von .NET die Notwendigkeit, Speicher selbst zu verwalten – dies geschieht implizit. Doch sie löst nicht alle Probleme, zudem verursacht sie neue Probleme, derer sich Entwickler zumindest in kleinen Anwendungen nicht bewusst werden.

Denn nach wie vor haben Entwickler mit hängenden Referenzen zu kämpfen, die beispielsweise dadurch entstehen, dass Ereignisse nicht auch wieder abgemeldet werden.

Ebenfalls problematisch ist das vermeintlich günstige Erzeugen neuer Objekte im Verlass darauf, dass die Garbage Collection die erzeugten Objekte wieder entfernen wird – Speicherverschwendung und damit Performanceprobleme auf Grund falsch angewandter Instanziierung sind eher die Regel denn die Ausnahme.

Auch der grafische, in Visual Studio enthaltene Designer für WPF stellt eine solche Abstraktion dar: Er entledigt den Entwickler von der lästigen Aufgabe, WPF-Code per Hand schreiben zu müssen – kann aber natürlich nie die wahre Absicht des Entwicklers erahnen und muss daher gewisse Kompromisse zwischen Generalität und vernünftigem, das heißt performanten und wohlstrukturierten Code eingehen.

Last but not least stellt selbst der Konkatenationsoperator für Zeichenketten, dargestellt durch ein vermeintlich harmloses +, eine Abstraktion über die Vorgänge dar, die im Speicher stattfinden, um zwei Zeichenketten miteinander zu einer neuen zu verbinden. Die Speicher- und Performanceimplikationen dürften hinlänglich bekannt sein.

All diese Probleme werden durch Abstraktionen verursacht, die ursprünglich angetreten sind, bestehende Probleme zu lösen. Natürlich kann man auf Abstraktionen auch nicht verzichten – zu essenziell sind sie für die überschaubare Lösbarkeit eines gegebenen Problems.

So erspart beispielsweise ASP.NET als Abstraktion über das HTTP-Protokoll – das seinerseits übrigens nichts anderes als eine weitere Abstraktion über den Datenverkehr im Netzwerk darstellt – dem Entwickler eine ganze Menge an Aufgaben, die in der Regel ohnehin immer nach dem gleichen Schema erledigt werden.

Doch – wer nicht weiß, was bei ASP.NET unter der Haube geschieht, neigt schnell dazu, die vorgegebenen Pfade als das Nonplusultra anzusehen und dabei auftretende Probleme zu ignorieren, schlichtweg, weil sie auf Grund der Abstraktion nicht wahrgenommen werden.

Das Paradoxe an dieser Situation ist, dass es – je mehr und mächtigere Abstraktionen verfügbar sind, desto schwieriger wird es, zu wissen, was man eigentlich macht. Damit schließe ich mich nahtlos Joel Spolsky an, wenn er in seinem eingangs erwähnten Artikel schreibt:

[…] all this means that paradoxically, even as we have higher and higher level programming tools with better and better abstractions, becoming a proficient programmer is getting harder and harder.

Schlussendlich lässt sich zusammenfassen, dass es für hervorragende Entwickler nicht genügt, sich mit ihrer jeweils präferierten Technologie auseinanderzusetzen, sondern dass sie sich – um wirklich verstehen und nachvollziehen zu können, was geschieht – auch mit den zu Grunde liegenden Technologien auseinandersetzen müssen.

Das bedeutet, dass auch – oder erst recht – in Zeiten von Hochsprachen, Frameworks, Designern und Assistenten die Berechtigung oder gar die Pflicht gegeben ist, sich mit den Grundlagen zu beschäftigen.

Dass dies nicht zuletzt auch eine große Herausforderung für die Ausbildung darstellt, sei es in Firmen, an Hochschulen oder in sonstigen Formen, liegt auf der Hand.

Werden die Grundlagen nämlich zu Gunsten schnellerer und vermeintlich besserer Lernerfolge systematisch ignoriert, bedeutet das, Oberflächlichkeit zu fördern und verstehendes Wissen unter Anwendung der Root Cause Analysis, die unter anderem auch von der Clean Code Developer-Initiative wertgeschätzt wird, zu missachten.

Nachdem ich gestern Morgen – direkt nach der Keynote – meine erste Session auf der VSone in München gehalten habe, war ich gestern am späten Nachmittag mit einer weiteren Session an der Reihe. Unter dem Titel

Singleton? Aber threadsicher!

verbarg sich augenscheinlich lediglich die Frage, wie das Entwurfsmuster Singleton threadsicher umgesetzt wird – doch der Teufel steckt bei dieser Frage im Detail.

Nachdem ich vor 11 Teilnehmern zunächst in knappen Worten die Frage erläutert habe, warum die klassische Implementierung nicht threadsicher ist, habe ich einige verbreitete threadsichere oder vermeintlich threadsichere Varianten vorgestellt.

Was als scheinbar leichte Aufgabe begann, endete letztlich in der Analyse des vom C#-Compiler erzeugten MSIL-Codes, der Diskussion über eine Aspekte der Spezifikation von C# und der Erklärung einiger Spitzfindigkeiten innerhalb der .NET-Runtime.

Im Wesentlichen habe ich in der Session dabei die folgenden Punkte behandelt:

• Singleton – klassisch
• Singleton threadsicher – mit Locking
• Singleton threadsicher – Double-checked locking idiom
• Singleton threadsicher – ohne Locking
• Verhalten von statischen Konstruktoren
• Felder vs Eigenschaften

Besonders gefreut hat mich, dass ich mit einer ebensolchen Spitzfindigkeit innerhalb der Runtime von .NET ein nicht reproduzierbares, sporadisch auftretendes Problem im Code eines Teilnehmers lösen konnte.

Das erste Feedback zeigt mir, dass die Session auch den anderen Teilnehmern sehr gut gefallen hat – was mehr kann man sich wünschen?

Heute und morgen findet im Neuen Forum am Deutschen Museum in München zum inzwischen sechsten Mal die VSone statt, unter deren Dach sich unter anderem auch die Advanced Developers Conference wiederfindet.

Dieses Jahr war ich erstmalig mit einem Vortrag auf der ADC vertreten. Im Rahmen meiner Session mit dem Titel

XP – Extreme Programming für .NET-Entwickler

habe ich XP als agile Methode vorgestellt, deren Werte und Techniken vorgestellt und die gängigen Kritikpunkte diskutiert. Als Kernelement der Session habe ich dabei auf die im agilen Manifest verankerten Werte zurückgegriffen, welche die Basis für sämtliche agilen Methoden bilden – sei es XP, Scrum, Chrystal oder eine beliebige andere agile Methode.

Wider mein persönliches Erwarten war die Session mit 34 Teilnehmern sehr gut besucht – dermaßen viel Interesse an XP hätte ich zunächst nicht erwartet. Im Wesentlichen habe ich in der Session die folgenden Punkte behandelt:

• Was ist eine agile Methode?
• Das agile Manifest
• Werte von XP
• Techniken von XP
• Anforderungsmanagement
• Gängige Kritikpunkte
• XP + Scrum?

Insgesamt bin ich sehr zufrieden, wie alles gelaufen ist, und das Feedback, das ich bislang von den Teilnehmern erhalten habe, zeigt mir, dass die Session informativ und unterhaltsam zugleich war und positiv aufgenommen wurde.

Von den zahlreichen Werkzeugen, die für die Softwareentwicklung auf Basis von .NET zur Verfügung stehen, sind nur einige wenige derart gelungen, dass sie ohne Wenn und Aber für wirklich jeden Entwickler empfehlenswert sind.

Zu diesen Werkzeugen zählen meiner Meinung nach unter anderem Resharper von JetBrains und .NET Reflector von Red Gate.

Resharper ist ein typisches Mausrad-Produkt: Eigentlich braucht man es nicht – aber nachdem man es für einige Weile genutzt hat, vermisst man es schmerzlich, wenn man dann ohne es auskommen muss. Erst in solchen Augenblicken spürt man, wie nützlich das Werkzeug ist, und wie nahtlos es sich in die eigene Arbeitsweise integriert.

.NET Reflector ist im Gegensatz zu Resharper bislang kein Addin für Visual Studio, sondern ein eigenständiges Produkt gewesen: Es ermöglicht das Disassemblieren und Rückübersetzen von Assemblies in zahlreiche Sprachen wie C#, Visual Basic oder auch MSIL.

Die Anwendungsgebiete sind vielfältig: Diese reichen von der Analyse von bestehendem Code zu Lernzwecken bis hin zur Fehlersuche in externen Assemblies. Zweifelsohne zählt .NET Reflector daher zu den Werkzeugen, die ein Entwickler früher oder später tatsächlich benötigt.

So praktisch .NET Reflector bislang war, so hakelig war auch die Bedienung: Da keine Integration in Visual Studio stattfand, musste .NET Reflector als eigenständiger Prozess nebenher laufen, die zu analysierenden Assemblies mussten per Hand gesucht und eingebunden werden, … nahtlose Integration sieht anders aus.

Vor einigen Tagen ist nun die neue Version 6 von .NET Reflector erschienen. Neben der Unterstützung von .NET 4.0 gibt es als neues Feature eine Integration in Visual Studio, die es ermöglicht, direkt aus dem Kontextmenü des Quellcodeeditors an die zugehörige Stelle innerhalb der disassemblierten Assembly zu springen.

Allein dieses Feature macht die Arbeit mit .NET Reflector bedeutend angenehmer und vor allem schneller, da aufwändige Suchen der Vergangenheit angehören. Aber – die neue Version bietet noch mehr: Erstmalig steht von .NET Reflector eine zweite Edition zur Verfügung: .NET Reflector Pro.

Die Webseite von Red Gate verspricht zu .NET Reflector Pro, dass es aus Visual Studio heraus möglich sein soll, Assemblies zu disassemblieren und diese disassemblierten Assemblies gemeinsam mit dem eigenen Code im Rahmen des Debuggers verwenden zu können.

Und – es funktioniert tatsächlich! .NET Reflector Pro verspricht nicht nur eine nahtlose Integration, tatsächlich ist es eine nahtlose Integration! So ist es mit .NET Reflector Pro problemlos möglich, gemeinsam mit eigenem Code die von dort verwendeten .NET-eigenen Assemblies Step-by-Step zu debuggen.

Kaum ein Produkt hat mich in den vergangenen Jahren derart begeistert wie .NET Reflector Pro – hinter einer schlichten und sehr kompakten Benutzeroberfläche verbirgt sich ein unglaubliches Potenzial.

Als einziger Wermutstropfen kann gelten, dass .NET Reflector Pro kostenpflichtig ist. Mit einem Preis von 145 Euro bewegt es sich aber – ebenso wie auch Resharper – in einem durchaus auch für private Entwickler erschwinglichen Rahmen, zudem muss man lange suchen, bis man ein weiteres Produkt mit einem ähnlichen, derart herausragenden Preis-Leistungs-Verhältnis findet.

Christian Wenz ist Autor, Trainer und Berater mit Schwerpunkt Webentwicklung und Websicherheit sowie Mitbegründer der Hauser & Wenz Partnerschaftsgesellschaft. Als Buchautor veröffentlicht er seit fast zehn Jahren zu allen wichtigen Webthemen. Er hat zahlreiche Fachartikel verfasst und spricht regelmäßig auf Entwicklerkonferenzen im In- und Ausland. Als Teilhaber der Agentur Arrabiata Solutions GmbH leitet er Entwicklungsprojekte und führt Security-Audits durch. Sie erreichen ihn über seine Webseite.

Golo Roden: Christian, wie bist Du zur Softwareentwicklung gekommen? Wie und wann hast Du angefangen?

Christian Wenz: Indirekt hat mich mein Vater dazu gebracht. Er war Richter und hat auch Rechtspfleger ausgebildet. Unter anderem hat er da auch Zeugnisse erstellen müssen, in denen immer dieselben Textbausteine, abhängig von der Prüfungsnote, zum Einsatz kamen. Dies erledigte er irgendwann auf einem C128 mit PROTEXT. Mich hat da natürlich zunächst eher der ebenfalls eingebaute C64 interessiert.

Für Summer Games und Winter Games gingen mehrere Joysticks drauf. Letztendlich entwickelte ich aber auch ein Interesse für BASIC, und in der Schule gab es dann einen Informatikkurs, in dem mit Pascal gearbeitet worden ist. Programmieren machte mir Spaß, ich habe auch ein paarmal am Bundeswettbewerb für Informatik teilgenommen und so lag es nahe, das Hobby irgendwann in welcher Form auch immer zum Beruf zu machen.

Ich habe bereits nach der Schule als Entwickler gearbeitet; Informatik hatte ich dann später parallel studiert, weil ich gehört hatte, man müsse da nicht programmieren. Hat zu großen Teilen sogar gestimmt.

Golo Roden: Zusammen mit Tobias Hauser hast Du die Hauser & Wenz Partnerschaftsgesellschaft gegründet. Wie kam es dazu?

Christian Wenz: Tobias kenne ich aus der Schule. Bereits kurz danach haben wir mit einem dritten unserer Altersstufe eine kleine Webagentur gegründet und dort doch recht beachtliche Anwendungen auf die Beine gestellt. Währenddessen habe ich auch bei einer größeren Münchner Agentur angeheuert und habe dort ein paar Jahre lang an ziemlich großen Projekten gearbeitet und hatte am Ende richtig viel Verantwortung.

Parallel habe ich angefangen, erste Bücher und Artikel zu schreiben, und später auch Tobias mit diesem „Virus“ infiziert. Als ich 2002 einmal eine Pause vom aufreibenden Agenturalltag einlegen wollte und wir beide in Hinblick auf die Wissensvermittlung eh sehr erfolgreich waren, haben wir beschlossen, unsere Zusammenarbeit auch firmentechnisch auf eine solide Basis zu stellen.

Letztendlich sind wir aber 2005 wieder zurück auf die Projektschiene gewechselt und haben zusammen mit drei weiteren Partnern die Arrabiata Solutions GmbH gegründet. Unsere Themen sind das klassische Webagenturgeschäft, vom Design über die Implementierung bis hin zur Wartung, aber auch zahlreiche Beratungstätigkeiten, beispielsweise im RIA- oder SEO-Umfeld oder bei der Technologiewahl und Onlinestrategie.

Zu unseren Kunden zählen international ausgerichtete Mittelständler und Großkonzerne, die Aufgaben sind also stets sehr spannend. Meine aktuellen Aufgabengebiete sind Performanceoptimierung von Websites, LOB-Anwendungen im Browser, Web Application Security und mobile Anwendungen.

Golo Roden: Ein wesentliches Merkmal der IT ist, dass man beständig mit neuen Entwicklungen konfrontriert wird, und diesen folgen muss. Woher nimmst Du die Motivation, Dich quasi jeden Tag weiterzubilden und mit Neuem zu beschäftigen?

Christian Wenz: Ich arbeite gerne als Wissensvermittler. Dazu gehört es eben auch, immer über aktuelle Entwicklungen informiert zu sein um am Ball zu bleiben. Allerdings denke ich, dass ich ein eher mittelmäßiger Autodidakt bin. Ich muss mich also mit einer Sache schon beschäftigen, um später qualifiziert beurteilen zu können, ob sie mich oder meine Kunden weiter bringt oder nicht.

Das treibt mich natürlich immer wieder an, neues Wissen zu erarbeiten und nicht nur oberflächlich aufzusaugen. Außerdem sehe ich immer wieder, dass ich auch von den Erfahrungen der Vergangenheit profitieren kann.

Der Ajax-Boom ab 2005 kam mir insofern sehr gelegen, weil ich fast zehn Jahre vorher angefangen hatte, JavaScript einzusetzen. Bei der aktuellen Debatte rund um Silverlight finde ich unsere Projekterfahrung mit Flash sehr wertvoll, weil einige Ansätze und Einschränkungen freilich sehr ähnlich sind.

Golo Roden: Wenn sich ein Anfänger heute mit dem Thema Softwareentwicklung befassen will – welche Voraussetzungen sollte er Deiner Meinung nach dafür mitbringen, und was siehst Du als No-Go an?

Christian Wenz: Wichtig sind zum einen Neugier und auch der Wille, sich mit der Thematik zu beschäftigen. Gerade Programmiersprachen vergeben nur wenige Fehler, das Frustpotenzial ist hoch. Etwas komisch klingt vielleicht noch, dass man ein Faible für Mathematik und Logik haben sollte. Denn da verhält es sich ähnlich wie in der Programmierung: es gibt klare Regeln und abstraktes Denken ist gefordert.

Das soll natürlich nicht heißen, dass man für die Arbeit als Softwareentwickler den Beweis für den großen Fermatschen Satz nachvollziehen und täglich zwanzig Sudokus im Kopf lösen können sollte, das trifft auch beides auf mich nicht zu – aber wenn in der Schule der Dreisatz schon eine gewisse Hürde darstellte, hat man es auch als Entwickler schwer. Heutzutage ist es – allein schon dank der verfügbaren Dokumentation und Google – sehr einfach, ein irgendwie funktionierendes Programm zu schreiben. Im beruflichen Umfeld spielt die Softwarequalität jedoch eine große Rolle. Und dazu braucht man – meiner Meinung nach – ein „Händchen“ für Mathe & Co.

Golo Roden: Welche Rolle spielt Engagement in der Community für Anfänger – so wohl aus Deiner wie auch aus deren Sicht?

Christian Wenz: Ich denke, das hängt von der Art der Community ab. Beispiel Usergroups: Ich schaffe es ja leider viel zu selten zu den Usergroups denen ich angehöre, im .NET-Umfeld beispielsweise MunichDot.NET, aber die Diskussionen dort sind immer sehr spannend und vielschichtig – fast noch besser als auf Konferenzen. Ein blutiger Anfänger würde sich da allerdings eher schwer tun.

Geht es um Community im Sinne von Blogs, Websites, Wikis und Foren, dann sind diese natürlich heutzutage unverzichtbar. Wobei ich persönlich ganz ehrlich gestehen muss, dass ich zum Beispiel keine Blogreader-Software mehr verwende. Es gibt zu viele interessante Blogs, und ich habe zu wenig Zeit. Um nicht ein zu langes Backlog zu bekommen, besuche ich eine Reihe von Blogs unregelmäßig, aber dennoch häufig; für wichtige andere Neuerungen und Informationen verlasse ich mich auf Suchmaschinen und Twitter.

Wenn ich mich zurück erinnere, wie ich damals mit der Entwicklung angefangen habe und welche Recherche- und Hilfemöglichkeiten es damals gab, so bin ich schon sehr froh, was heute alles zur Verfügung steht. Da ich sehr viel aus der Community ziehe, halte ich es für selbstverständlich, ebenfalls beizutragen. Ich veröffentliche ziemlich viel, spreche sehr gerne vor Usergroups, auch über das INETA Speaker’s Bureau, organisiere und plane technische Veranstaltungen mit und trete natürlich vor allem auf Konferenzen auf. Das Schöne an funktionierenden Communitys: Nur wenige möchten nur bedienen; die meisten tragen nach ihren Möglichkeiten bei. So ist am Ende jeder etwas schlauer als vorher.

Golo Roden: Bei der Vielzahl an Technologien, die es heute gibt: Womit sollte ein Anfänger heutzutage anzufangen?

Christian Wenz: Zum Glück gibt es heutzutage für fast jede Sprache Möglichkeiten, kostenlos mit (fast) professionellen Mitteln zu entwickeln, seien es Microsofts Express Editions oder Eclipse samt seiner verschiedensten Plugins. Ich würde zunächst die Grundlagen der Programmierung lernen, am besten mit besonders einsteigerfreundlichen Sprachen, beispielsweise (Visual) Basic oder auch PHP.

Sobald die Grundlagen sitzen, würde ich mich recht schnell entscheiden, an welcher Art von Anwendungen ich im nächsten halben Jahr experimentieren will: Web? Fat Client? Mobile?

Dahingehend würde ich dann eine Sprache und/oder Technologie aussuchen. Ich denke, die „klassische“ Meinung ist, dass man mit einer „Lehrsprache“ wie etwa Pascal beginnen, alle wichtigen Grundlagen lernen und dann das Wissen auf jede beliebige andere Technologie übertragen sollte. Ich bin ja einen ähnlichen Weg gegangen.

Aber ich denke, es motiviert mehr, wenn man sein sich aufbauendes Wissen gleich in praktische Ergebnisse umsetzen kann. Übrigens konnte ich das damals sogar, denn Pascal war „in“ und Anwendungen eh meist nur Konsolenapplikationen.

Golo Roden: Neben .NET beschäftigst Du Dich auch mit PHP. Wo siehst Du die Stärken und Schwächen der jeweiligen Plattformen?

Christian Wenz: Typische Berater-Antwort: „Hängt davon ab“. Prinzipiell ist PHP natürlich von der Marktverbreitung her aktuell die unangefochtene Nummer 1. Beispiele wie Yahoo! und Facebook zeigen, dass sich Enterprise und PHP keineswegs ausschließen.

PHP ist sehr funktionsreich, performant, einsteigerfreundlich, wird durch eine extrem große Community unterstützt – und ist leider historisch gewachsen. ASP.NET ist etwa fünf Jahre jünger und mir gefällt der Steuerelementsansatz, der PHP im Wesentlichen fehlt. Allerdings gibt es auch einige webuntypische Einschränkungen und Eigenheiten, die gerade im klassischen Agenturalltag zu Stirnrunzeln führen.

Wir haben in beiden Technologien große Projekte erfolgreich umgesetzt. Mehr „Massengeschäft“ machen wir allerdings im PHP-Umfeld, insbesondere da es dort mehrere vernünftige freie Content-Management-Systeme gibt. Die Entscheidung welche Technologie es im Projekt letztendlich wird, hängt immer von mehreren Faktoren ab, unter anderem der bisherigen Systemstruktur des Kunden, dem Skillset der Entwickler, falls es nicht die eigenen sind, politisch motivierten Präferenzen und so weiter.

Golo Roden: Welchen Rat würdest Du einem Anfänger abschließend mit auf den Weg geben?

Christian Wenz: Neugierig sein. Kleine Schritte machen. Sich nicht von didaktisch miesem Lernmaterial und von zu anspruchsvollen Koryphäen frustrieren lassen – viele Veröffentlichungen haben ungeplant arg hohe Voraussetzungen. Und vielleicht nochmal das mit dem Dreisatz üben.

Am 1. Januar 2010 hat Peter Bucher die erste Version seines neu entwickelten Microkernels LightCore veröffentlicht. Seitdem sind bereits wieder einige Features hinzugekommen, die allerdings derzeit nur in der Entwicklerversion zur Verfügung stehen, die als Quellcode aus dem zugehörigen Subversion-Repository abgerufen werden kann.

Nach wie vor halte ich LightCore für einen äußerst bemerkenswerten Microkernel und Dependency Injection-Container, auch die intensive Nutzung hat meiner Begeisterung keinen Abbruch getan – im Gegenteil.

Und dennoch – es gibt eine Kleinigkeit, die mich bislang gestört hat: Peter stellt LightCore lediglich als nicht-signierte Assemblies bereit. Das bedeutet, dass jeder, der wie ich eine signierte Variante benötigt, sich zunächst den Quellcode herunterladen, ihn anpassen und neu übersetzen muss.

Peter und ich haben daher beschlossen, dass ich zukünftig den jeweils aktuellen Stand von LightCore als signierte Version zur Verfügung stellen werde. Signiert sind dabei die folgenden drei Assemblies:

• LightCore.dll
• LightCore.Configuration.dll
• LightCore.Integration.Web.dll

Nicht signiert ist die LightCore.CommonServiceLocator.dll, da diese von einer zumindest derzeit ebenfalls nicht signierten Assembly von Microsoft abhängt. Da es in .NET aus Sicherheitsgründen nicht möglich ist, aus einer signierten Assembly auf eine nicht-signierte Assembly zu verweisen, kann die LightCore.CommonServiceLocator.dll vorerst nicht signiert werden.

Der Download der signierten Variante von LightCore findet sich als ZIP-Archiv unter http://www.goloroden.de/Downloads/LightCore.aspx, wobei darin ebenfalls die nicht-signierte vierte Assembly enthalten ist.

In den nächsten Tagen wird dieser Link dann auch auf der offiziellen Webseite von LightCore verfügbar sein, so dass auch zukünftig alle verfügbaren und offiziellen Downloads dort aufgelistet sind.

Am 13. Oktober 2008 haben Peter Bucher und ich unter dem Titel Noch Fragen, Bucher? Ja, Roden! angekündigt, jeweils zum ersten eines jeden Monats einen Kommentar zu einem vorab gemeinsam gewählten Thema verfassen zu wollen. Bisher sind in dieser Reihe folgende Kommentare erschienen:

• 1. Januar 2010: this oder kein this?
• 1. Dezember 2009: Reflection – Fluch oder Segen?
• 1. November 2009: Wie viel Sinn machen Unittests?
• 1. Oktober 2009: Vererben oder aggregieren?
• 1. September 2009: Alles var – oder nicht?
• 1. August 2009: C# oder VB: Welche Sprache soll ich lernen?
• 1. Juli 2009: Primärschlüssel: GUID vs Identity
• 1. Juni 2009: Heißt die Zukunft RIA?
• 1. Mai 2009: Woran erkennt man einen guten Entwickler?
• 1. April 2009: Interfaces vs abstrakte Basisklassen
• 1. März 2009: Sinn und Zweck von AOP
• 1. Februar 2009: Die Forderung nach Softwarequalität
• 1. Januar 2009: SOA vs WOA
• 1. Dezember 2008: Dynamic Language Runtime: .NET, quo vadis?

Heute, am 1. Februar 2010, ist es nun wieder so weit, und unser Thema für diesen Monat lautet:

Felder vs Eigenschaften

So wohl Peter wie auch ich haben uns unabhängig voneinander im Vorfeld unsere Gedanken gemacht, wie wir diesem Thema gegenüberstehen. Peters Kommentar findet sich zeitgleich in seinem Blog, folgend nun mein Kommentar zu diesem Thema:

Im Gegensatz zu klassischen Sprachen wie C++ oder Java verfügt C# seit der ersten Version über das Konzept der Eigenschaften: Ein für den Entwickler leichtgewichtiges und syntaktisch komfortables Konzept zum kontrollierten Zugriff auf Felder.

Gerade im Vergleich zu den in den genannten Sprachen üblichen zahlreichen Get- und Set-Methoden, die zum Zugriff auf Felder notwendig sind, bieten Eigenschaften einen enormen Vorteil, insbesondere im Hinblick auf die einfachere Lesbarkeit und damit auch bessere Verständlichkeit von Code.

Allerdings wird – beispielsweise in reinen Datenklassen – für den Zugriff auf Felder kein aufwändiger Zugriff benötigt, so dass die Definition einer Eigenschaft in der Regel zum einen immer nach dem gleichen Schema abläuft, zum anderen aber auch syntaktisch aufwändig und redundant ist.

Diesem Umstand trägt C# seit der Version 3.0 mit automatisch implementierten Eigenschaften Rechnungen, wodurch bereits deutlich weniger Code zu schreiben ist – allerdings immer noch deutlich mehr, als für ein Feld, das mit dem Zugriffsmodifizierer public ausgestattet wird.

Nun könnte man meinen, dass man an Stelle einer ohnehin leeren Eigenschaft durchaus ein öffentliches Feld verwenden könnte – doch es gibt einige Gründe, warum man dies unterlassen sollte:

• MSIL-Code: Felder und Eigenschaften werden in unterschiedlichen MSIL-Code übersetzt, sind also binär nicht kompatibel zueinander. Im Nachhinein lässt sich ein Feld also nicht ohne weiteres durch eine gleichnamige Eigenschaft ersetzen, ohne abhängigen Code – beispielsweise in anderen Assemblies – zu brechen.
• Referenzparameter: Felder können im Gegensatz zu Eigenschaften einer Methode als Referenzparameter übergeben werden. Deshalb kann ein Ersetzen eines Feldes durch eine Eigenschaft dazu führen, dass Methodenaufrufe nicht mehr kompiliert werden können, bei denen die Übersetzung zuvor ohne weiteres möglich war.
• Reflection: Die Arbeit mit Feldern und Eigenschaften gestaltet sich per Reflection unterschiedlich, so dass ein Ersatz eines Feldes durch eine Eigenschaft ebenfalls wiederum abhängigen Code brechen könnte.
• OOP: Es widerspricht dem objektorientierten Konzept der Informationskapselung, Felder als nicht-private zu markieren.
• Debugger: Eigenschaften ermöglichen das Setzen eines Haltepunktes beim Auslesen beziehungsweise Schreiben, für Felder ist dies nicht möglich.
• Datenbindung: Eigenschaften können im Gegensatz zu Feldern für die Datenbindung an Steuerelemente herangezogen werden.

Kurzum: Felder sollten ausschließlich mit dem Zugriffsmodifizierer private versehen werden, für alle anderen Anforderungen sind Eigenschaften in jedem Fall die bessere Wahl.

Ralf Westphal ist freier Softwaretechnologievermittler, Mitgründer des Professional Developer College und Mitinitiator von Clean Code Developer. Er war von 1998 bis 2005 einer der unabhängigen Microsoft Regional Directors für Deutschland und wurde von Microsoft als MVP „Visual Developer Solution Architect“ ausgezeichnet. Sie erreichen ihn über seine Webseite.

Golo Roden: Ralf, wie bist Du zur Softwareentwicklung gekommen? Wie und wann hast Du angefangen?

Ralf Westphal: Wenn ich mich recht erinnere, habe ich 1980 mit dem Programmieren angefangen. Oder war es schon 1979? Jedenfalls stand am Anfang ein Büchlein mit einer Einführung in Pascal. Ganz ohne Computer habe ich das in einem Urlaub durchgearbeitet. Da ging es vor allem um Algorithmen: Sortieren, die Türme von Hanoi und solche Sachen. Danach dann die offizielle Pascal Sprachdefinition. Die hat mich mit der EBNF konfrontiert. Nach dem Urlaub begann der Informatikunterricht in der Schule. Für den hatte ich mich fit gemacht. Unterrichtssprache Pascal. Auf einer Dietz-Anlage mit Bernsteinterminals. Der Lehrer war durchaus bemüht und offen für unsere Ideen. War eine lustige Zeit.

Irgendwie in der Zeit habe ich mich dann auch um einen Computer zu Hause bemüht. Am Anfang war das ein Tandy TRS-80. Darauf habe ich Z-80-Assembler programmiert, zum Beispiel einen Texteditor. Danach kam ein Apple II mit CP/M-Betriebssystem, weil ich weiter Z-80-Assembler programmieren können wollte. Mit Apple Basic habe ich nur wenig gemacht – aber doch zumindest einen ersten Job realisiert. Und meinen ersten Artikel für die damalige Computer Persönlich-Zeitschrift von Markt + Technik habe ich auch über ein Programm in Apple Basic geschrieben. Da ging es irgendwie um die Komprimierung von Programmcode, weil der Hauptspeicher so begrenzt war. Der nächste Artikel hat sich auf der Basis von UCSD Pascal mit 3D-Grafiken beschäftigt.

Als ich 1983 zur Bundeswehr kam, habe ich den Apple mitgenommen und einige Verwaltungsaufgaben damit auf dem Geschäftszimmer erledigt. Ich wurde dort eingesetzt, weil ich durch die Computerarbeit flüssig mit einer Schreibmaschine beziehungsweise einer Tastatur umgehen konnte.

Und weiter? Hm ... in der Uni haben wir eher auf größeren Anlagen gearbeitet. Da erinnere ich mich an ein Seminar in Assembler. Ausbildungssprache Pascal. Gelernt habe ich dort nicht mehr viel. Privat ging es mit Turbo Pascal weiter. Das hatte ich seit meiner Schulzeit, fand es supercool und habe sogar ein Lehrbuch für die Schule dazu geschrieben. Leider ist das nie zum Einsatz gekommen.

Später bin ich auf C und Modula mit CP/M umgestiegen. Das war leading edge technology damals. Beides war von der Firma Lightspeed und konnte sogar zusammengelinkt werden.

„Auf der Arbeit“ bin ich eher mit Unix konfrontiert worden. Zum Beispiel habe ich für ein Forschungsinstitut einen Ganzseiteneditor gebastelt, mit dem man vernünftig – so wie damals mit WordPerfect – Prolog-Code schreiben konnte. VI war den Forschern und auch mir zu umständlich.

Weiter ging es mit 4GL-Sprachen und Smalltalk. Und schließlich ab 1990 C++ für ein bis zwei Jahre. Ab Visual Basic 1.0 dann Visual Basic bis zum Abwinken.

Golo Roden: Du hast Dich auf die .NET-Plattform spezialisiert. Warum gerade .NET und nicht beispielsweise JEE (Java Enterprise Edition)?

Ralf Westphal: Java hat mich 1995 interessiert. „Java in a Nutshell“ oder so hatte ich schon vor dessen Erscheinen bestellt. Ich fand die Sprache auch cool – sie bot damals wegen ihres Fokus auf die Webentwicklung nichts für die Desktop-Branchensoftwareentwicklung. Von 1987 bis 1998 habe ich ja mit einem Partner ein Branchensoftware-Schmiede gehabt – er macht das auch heute noch –, bei der wir MS-DOS- und später Windows-Anwendern etwas bieten mussten. Das Web war ja nur für mutige Early Adopters interessant. Nach einer 4GL-Lösung, die wir ab 1987 entwickelt hatten – und die auch heute noch bei einigen Anwendern im Einsatz ist! – hatten wir auf Visual Basic gesetzt. C++ war uns zu umständlich, Delphi noch nicht ausgereift genug. Also Visual Basic von 1.0 bis 6.0. Außerdem kam dann 1996 / 1997 oder so ASP um die Ecke, so dass wir im Web auch mit unseren Visual Basic-Kenntnissen arbeiten konnten. Java bot uns angesichts dessen zuwenig. Damit war die Weiche gestellt. Als ich 2000 .NET auf der PDC gesehen hatte, wusste ich, dass das der natürlich weitere Weg sein würde.

Golo Roden: Ein wesentliches Merkmal der IT ist, dass man beständig mit neuen Entwicklungen konfrontriert wird, und diesen folgen muss. Woher nimmst Du die Motivation, Dich quasi jeden Tag weiterzubilden und mit Neuem zu beschäftigen?

Ralf Westphal: Das ist mein Job. Dieselbe Antwort gibt dir ja auch ein Bäcker, wenn du ihn nach der Motivation fragst, die ihn jeden Tag Brötchen backen lässt. Im Vergleich zum Entwickler in einem Projekt empfinde ich also keine Spannung zwischen „Arbeit“ und „Fortbildung“. Meine Arbeit ist Fortbildung. Der Zweck: Anderen mit meinem Wissen zu helfen. Ich bin kein „Programmierer“, sondern eher „Softwaretechnologievermittler“. „Trainer“ wäre zu eng gefasst, „Lehrer“ zu institutionell, „Berater“ auch zu eng. Also „Technologievermittler“ und „One Man Think Tank“. Diese Bezeichnung habe ich nach einigem Grübeln gewählt für meine „Firma“ gewählt, weil sie ausdrückt, was und wie ich arbeite: In der Form bin ich Freiberufler, arbeite also allein. Zumindest habe ich solch einen Hut, den ich aufsetze. Inzwischen gibt es noch andere wie „Mitgründer des Professional Developer College“ oder „Mitinitiator von Clean Code Developer“. Wenn ich diese Hüte aufsetze, arbeite ich nicht allein, sondern mit Partnern. Ursprünglich war ich aber eben reiner „Einzelkämpfer“ seit 1998, also „One Man“ Show.

Der „Think Tank“ beschreibt eher den Inhalt meiner Arbeit. Mein Job ist das Nachdenken, das Tüfteln, Ausprobieren. Ich möchte es fast schon als Forschung bezeichnen. Meine Ergebnisse sind weniger Code, als vielmehr Konzepte, Ansätze. Damit erlaube ich mir etwas, das sich viele Unternehmen und Teams nicht erlauben. Während Kollegen eher „normale“ Beratung machen, bei der sie sich auf Technologien konzentrieren, deren Einsatz begleiten oder sie gar für ihre Kunden einsetzen, bewege ich mich oft eine Ebene darüber, das heißt im Konzeptionellen.

Natürlich programmiere ich auch. Jeden Tag. Ich habe also keine Angst, abzuheben. Doch wenn schon die Firmen ihren Kopf nicht aus dem Sand der Projekte heben können, dann will zumindest ich das tun. Das macht mir Spaß, das kann ich – so glaube ich – ganz gut. So sehe ich mich als Ergänzung zu Teams, die sie bei Bedarf „zuschalten können“. Die externe Forschungsabteilung, der Blick von außen, der Spiegel, der Fragensteller, der Impulsgeber.

Damit ich das alles sein kann, muss ich halt immer etwas Neues auf der Pfanne haben, lesen und nachdenken. Früher hatte ich da mal Angst, dass ich da an eine inhaltliche oder motivationale Grenze stoßen könnte. Bisher spüre ich davon nichts. Vor 18 Monaten hatte ich noch keine Ahnung, dass ich heute mit Clean Code Developer unterwegs sein würde. Was in 18 Monaten ist, weiß ich auch nicht. Ich bin aber gewiss, da wird mich etwas Neues, Spannendes beschäftigen, das ich dann in die Community tragen kann.

Golo Roden: Wenn sich ein Anfänger heute mit dem Thema Softwareentwicklung befassen will – welche Voraussetzungen sollte er Deiner Meinung nach dafür mitbringen, und was siehst Du als No-Go an?

Ralf Westphal: Welche Art Anfänger meinst du? Einen Schüler, der noch nicht so recht weiß, was er mal werden will? Oder jemanden, der schon in eine Informatikausbildung eingestiegen ist? Oder jemanden, der gerade damit fertig geworden ist?

So ganz allgemein und grundlegend würde ich mal sagen, dass jemand, der sich mit Softwareentwicklung beschäftigen will, Spaß am Nachdenken haben sollte. Das Denken, Nachdenken, Selbstdenken steht de facto leider nicht wirklich hoch im Kurs in unserer Gesellschaft. Zwar sollen Schüler das Denken lernen – dafür ist Schule ja da –, doch passiert das nicht verlässlich genug, meine ich. Solange noch Talentshows und Sport solchen Raum in den Medien einnehmen, wie sie es tun. Solange sich die Nation so unverhältnismäßig über etwas wie die Schweinegrippe echauffieren kann. Solange es gesellschaftsfähig ist, mit technischer, geschichtlicher, philosophischer Unbildung zu kokettieren, solange steht Nachdenken einfach nicht hoch im Kurs.

Das soll jetzt natürlich nicht bedeuten, dass die Welt mehr freiberufliche Nachdenker wie mich braucht. Ich meine nur, dass in der Softwareentwicklung, deren Materie das Virtuelle und Abstrakte ist, Nachdenken ganz wichtig und daher Spaß am Nachdenken Voraussetzung ist. Software entsteht zunächst im Kopf durch rigoroses, systematisches und kreatives Denken mit einer gehörigen Portion Reflexion und Skepsis.

Zum Spaß am Denken sollte dann noch Spaß am grundsätzlich Technischen kommen. Auch da steht es leider in der Grundausbildung schlecht. Technische Unbildung grassiert. Nicht nur ist den meisten schon der Dreisatz ein Buch mit sieben Siegeln, auch die mechanische oder elektronische Funktionsweise von Maschinen interessiert viele nicht. Was unsere moderne Welt zusammenhält – Technologie – wird nicht systematisch als interessant vermittelt. Fernseher und Computer und Handy benutzen alle gern – doch die nächsten Generationen selbst mitgestalten, dazu haben sie keine rechte Lust. Anders kann ich mir die sinkenden Studentenzahlen bei der Informatik nicht erklären.

Zum Spaß am Denken und an Technik im Allgemeinen – Grundfrage: Wie funktioniert das? – sollten noch Fertigkeiten der Visualisierung treten. Software entsteht im Kopf und muss dann kommuniziert werden. Nicht unbedingt in Form von Code, sondern zuerst einmal mit Bildern. Auch Nachdenken profitiert von Bildern. Wer ein gutes Vorstellungsvermögen hat – vor allem ein bildliches – und seine Vorstellungen dann auch noch anderen vermitteln kann, der hat einen Vorsprung. Das habe ich gerade gestern beim Unterricht in der School of .NET gesehen. Die Teilnehmer konnten sich eine Lösung für eine Übungsaufgabe so schwer vorstellen; ihnen fehlten Bilder für ein Modell. Deshalb gab es dann Probleme bei der Codierung.

Noch allgemeiner als Fertigkeiten zur Visualisierung sind solche zur Kommunikation schlechthin. Software ist kein Business für „lonesome rangers“. Der einsame Hacker ist out. In sind Entwickler, die fachliche und methodische Kompetenzen, die sie in einer Ausbildung erwerben, dank Softskills in ein Team einbringen können. Wissen und Ideen nicht nur visuell vermitteln können, sondern auch verbal, das ist wichtig. Zuhören können, emotionale Kompetenz, Selbstdisziplin, moderieren, ... das sind Fertigkeiten, die wir brauchen. Software entsteht im Team.

Die Motivation für eine Karriere in der Softwareentwicklung kommt also für mich aus dem Spaß am Denken, am Abstrakten und an Technik. Die Fähigkeit, sich dann auch erfolgreich einzubringen, machen Softskills aus. Fachkompetenz vermittelt – hoffentlich – eine Ausbildung.

Golo Roden: Gemeinsam mit Stefan Lieser hast Du die Initiative „Clean Code Developer“ ins Leben gerufen. Welche Bedeutung misst Du diesem Thema bereits für Anfänger bei?

Ralf Westphal: Die Bedeutung von Clean Code Developer für Anfänger ist nicht zu überschätzen! Hohe innere Qualität ist keine Sache für fortgeschrittene Entwickler. Sie muss vielmehr vom ersten Tag der Ausbildung an Thema sein. Das ist auch der Grund, warum mich so viele Lehrpläne von Berufsschulen und Universitäten traurig machen. Sie vermitteln einzelne technische Fertigkeiten – aber kein qualitätsorientiertes Bild von der Softwareentwicklung. Beispiel Berufsschule, Ausbildung zum Fachinformatiker Anwendungsentwicklung (FIAE): Nur ein Achtel des Unterrichts sind überhaupt der Softwareentwicklung gewidmet, der Rest beschäftigt sich mit Deutsch, Religion und anderen Themen. Von diesem Achtel beschäftigen sich in einem Semester vielleicht fünf Prozent mit dem Thema Testen. Das sind weniger als ein Prozent in einem Jahr und auf drei Jahre gerechnet vielleicht 0,5 Prozenz, wenn es hoch kommt. Was wollen wir denn da erwarten von ausgebildeten FIAE, wenn sie während oder nach der Ausbildung im Projekt sitzen? Fangen die dann plötzlich mit TDD an?

Für mich liegt die Ausbildung solange im Argen, wie das Thema Testen nicht von der ersten Stunde an konsequent während des ganzen Unterrichts präsent ist. Soviel zum Thema Korrektheit. Dasselbe gilt für die anderen CCD-Werte wie Evolvierbarkeit, Produktionseffizienz und Reflexion.

Vom ersten Tag an. Die ganze Ausbildung durch. Immer. Nur wer diese Werte konsequent bewusst hält, kann am Ende erwarten, sie auch unter Projektdruck nicht zu verraten.

Klar, man kann auch später noch dazu lernen. Aber dann ist es schwieriger. Dann sind eingefahrene Gewohnheiten zu entlernen. Das macht große Mühe – und die Codebasis ist schon ein Brownfield. Warum also nicht mit CCD bei den Anfängern beginnen?

Golo Roden: Bei der Vielzahl an Technologien, die es heute gibt: Womit sollte ein Anfänger heutzutage anzufangen?

Ralf Westphal: Keine Ahnung. Es gibt keinen richtigen Einstieg in Technologien – oder gar Produkte. Die unterliegen ja auch Moden. Selbst wer heute mit PHP beginnt, kann einen guten Job bekommen, glaube ich. Insofern ist die Frage, ob jemand dazu fähig ist, sich selbst und die Marktentwicklung zu reflektieren. Wer das kann, kann dann nämlich auch reagieren. Der fängt mit PHP an und sattelt später um auf Erlang oder so.

Was nutzbringend ist, hängt vom Umfeld ab. Für einen Studenten wäre es vielleicht nicht sehr nützlich, wenn er sich als einziger in seinem Umfeld mit Axum beschäftigt. Dann gehen ihm soziale Kontakte und dadurch Möglichkeiten zum Austausch verloren. Die sind nicht zu verachten.

Ich denke, jeder ist gut beraten, seine Neigungen zu erspüren. Mag man es lieber visuell oder lieber persistent? Mag man es lieber enterprisegroß oder branchensoftwareklein? Das lässt sich aber womöglich erst mit der Praxis erfahren. Als Anfänger muss man deshalb wahrscheinlich einfach mit irgendetwas anfangen.

Technologien sind auch nicht so wichtig. Wichtiger sind Paradigmen und Konzepte. Die Frage sollte also lauten, mit welchen der Paradigmen sollte sich ein Anfänger auseinandersetzen. Da liegt die Objektorientierung nahe. Aber ich füge gleich einmal die Komponentenorientierung hinzu. Da liegt Agilität nahe. Da liegt die asynchrone Programmierung nahe. Da liegen Algorithmen und Datenstrukturen nahe. Ja, auch und gerade die. Da liegen Kommunikationskonzepte wie Nachrichtenorientierung und ereignisgesteuerte Architekturen (EDA) nahe.

Aber ob man sich damit nun auf der Java- oder .NET- oder Ruby-Plattform beschäftigt, ist recht egal. Und ob es bei .NET nun NServiceBus oder MassTransit für EDA ist, ob O/R-Mapping mit OpenAccess oder NHibernate gelernt wird, ... das ist egal.

Die wesentliche Invariante ist: Alles ändert sich. Also nicht anhaften. Keine Paradigma, kein Konzept und schon gar kein Produkt auf einen Thron heben. Denn wo gestern ASP oder Java-Applets die Bringer waren, da ist heute Silverlight der Hit. Alles fließt – wusste schon Heraklit, der unsere Branche nicht kennen konnte-

Golo Roden: Welchen Rat würdest Du einem Anfänger abschließend mit auf den Weg geben?

Ralf Westphal: Widerstehe dem oft ignoranten Druck im Projekt. Da wird auf die Tube gedrückt, da wird keine Zeit für Fortbildung gegeben, da wird kein Wert auf Evolvierbarkeit gelegt. Vor 150 Jahren waren Arbeitsbedingungen in Fabriken mit 16 Stunden Arbeitszeit bei Dreck, Lärm und kärglicher Bezahlung unmenschlich. Heute ist es natürlich viel besser – und auf der anderen Seite immer noch schlimm. Anders schlimm, subtiler schlimm.

Heute stimmt zwar die Bezahlung und so ganz grundsätzlich meist auch die Arbeitszeit. Aber vieles andere stimmt immer noch nicht oder nicht mehr. Menschen wollen es bei der Arbeit nicht nur warm haben und Geld heimtragen, sondern auch Spaß haben und sich einbringen. Dazu sind viele Projekte nicht angetan. Leider.

So mancher Chef schaut – aus welchem Grund auch immer – nur darauf, dass möglichst schnell irgendwie der Kunde befriedigt wird. Das ist kurzfristiges Denken, bei dem Kreativität und Motivation und Qualität über kurz oder lang auf der Strecke bleiben.

Deshalb rate ich, hier sehr sensibel zu sein. Fortbildung ist nicht nur Sache des Mitarbeiters. Innere Softwarequalität ergibt sich nicht von selbst. Motivation ist nicht egal. Wo Projekte darauf keinen Wert legen, ist daher Gefahr im Verzug. Gefahr der baldigen Unzufriedenheit, weil die technische Schuldenlast den Spaß an der Arbeit vergällt. Wer im Brownfield-Morast steckt und auch noch unter Druck arbeitet, treibt auf den Burnout zu.

Aber nicht nur Unlust droht, sondern schlicht schlechtere Chancen auf dem Arbeitsmarkt. Wer keine Gelegenheit zur Fortbildung bekommen hat und nach zehn Stunden am Arbeitsplatz nicht mehr selbst die Energie aufbringen konnte, der fällt zurück. In fünf Jahren hat er den Anschluss verpasst. Heute zum Beispiel noch Visual Basic 6.0-Projekte zu warten, ohne aktiv an .NET-Projekten zu arbeiten, ist unverantwortlich, würde ich sagen. Da wird nicht nur die Visual Basic 6.0-Altlast fortgesetzt, sondern auch eine Entwickleraltlast produziert.

Letztlich ist das jedoch eine Entscheidung, die jeder Entwickler selbst treffen muss. Welche Arbeitsbedingungen will ich zu welchem Preis aushalten? Also: Augen offen halten. Was tut sich in der Softwarewelt? Wenn die Differenz zur eigenen Welt zu groß wird – das kann schnell geschehen –, dann handeln. Insofern sollten Softwareentwickler auch einiges an Veränderungsfreude mitbringen.

Nachdem ich vor knapp zwei Wochen einen Review über das Buch Pragmatic Unit Testing veröffentlicht habe, begann ich mit der Lektüre des nächsten Buchs: Cloud Computing mit der Windows Azure Platform von Holger Sirtl.

Der Untertitel verspricht Informationen zu der Entwicklung, der Integration und dem Betrieb cloud-basierter Anwendungen – was dann jedoch auf den ersten 75 Seiten mehr als ausreichend beschrieben wird, sind die allgemeinen Vor- und Nachteile von Clouds im Allgemeinen und von Windows Azure im Speziellen.

Obwohl dies prinzipiell nicht verkehrt ist, weist es die Tendenz für den weiteren Verlauf des Buchs: Der Inhalt, der auf rund 350 Seiten vermittelt wird, würde problemlos auf 200 Seiten passen, würden die ständigen Wiederholungen entfallen. Ungewollt beschleicht einen immer wieder das Gefühl, bestimmte Formulierungen schon einmal gelesen zu haben.

Sobald das Buch zu seinem fachlichen Teil kommt, steigt die Qualität des Inhalts deutlich an: Alle wichtigen Konzepte von Windows Azure werden erläutert und mit Beispielen demonstriert:

• Web Role und Worker Role
• Blobs, Tables und Queues
• Live Services
• .NET Service Bus
• .NET Access Control
• Deployment

Allerdings lässt das Buch auch hierbei einen kompakten Schreibstil vermissen und besteht zum Großteil aus den immer gleichen Formulierungen.

Vermisst habe ich bei dieser Ausführlichkeit einige grundlegende Erklärungen, speziell das Kapitel zu den Live Services erläutert zahlreiche Begriffe nur äußerst knapp und verwendet diese danach wie selbstverständlich – für jemanden, der noch nie mit Windows Live entwickelt hat, gestaltet sich dieses Kapitel dadurch verhältnismäßig schwierig.

Abgerundet werden diese Themen durch einige Beispiele für den Software plus Services-Ansatz, vom Desktopclient über Web- bis hin zu mobilen Anwendungen ist alles dabei, was für einen Entwickler interessant sein könnte. Auch das Thema Interoperabilität mit Java, PHP und Ruby wird angesprochen.

Insgesamt erhält man einen guten Überblick zu Windows Azure, dem es allerdings auf der einen Seite teilweise an Tiefe fehlt, und der auf der anderen zu sehr in die Länge gezogen ist. Sofern man sich damit arrangieren kann, ist das Buch kein schlechter Einstieg in Windows Azure – wer ein rundum empfehlenswertes Buch erwartet, sollte Abstand nehmen.

Am 13. Oktober 2008 haben Peter Bucher und ich unter dem Titel Noch Fragen, Bucher? Ja, Roden! angekündigt, jeweils zum ersten eines jeden Monats einen Kommentar zu einem vorab gemeinsam gewählten Thema verfassen zu wollen. Bisher sind in dieser Reihe folgende Kommentare erschienen:

• 1. Dezember 2009: Reflection – Fluch oder Segen?
• 1. November 2009: Wie viel Sinn machen Unittests?
• 1. Oktober 2009: Vererben oder aggregieren?
• 1. September 2009: Alles var – oder nicht?
• 1. August 2009: C# oder VB: Welche Sprache soll ich lernen?
• 1. Juli 2009: Primärschlüssel: GUID vs Identity
• 1. Juni 2009: Heißt die Zukunft RIA?
• 1. Mai 2009: Woran erkennt man einen guten Entwickler?
• 1. April 2009: Interfaces vs abstrakte Basisklassen
• 1. März 2009: Sinn und Zweck von AOP
• 1. Februar 2009: Die Forderung nach Softwarequalität
• 1. Januar 2009: SOA vs WOA
• 1. Dezember 2008: Dynamic Language Runtime: .NET, quo vadis?

Heute, am 1. Januar 2010, ist es nun wieder so weit, und unser Thema für diesen Monat lautet:

this oder kein this

So wohl Peter wie auch ich haben uns unabhängig voneinander im Vorfeld unsere Gedanken gemacht, wie wir diesem Thema gegenüberstehen. Peters Kommentar findet sich zeitgleich in seinem Blog, folgend nun mein Kommentar zu diesem Thema:

Zumeist sind Schlüsselwörter innerhalb einer Programmiersprache mit einer eindeutigen Semantik belegt; auch C# stellt keine Ausnahme dieser Regel dar. Jedoch gilt dies zumindest in C# wohlgemerkt nicht für alle Schlüsselwörter, denn einige haben – je nach Kontext – verschiedene Bedeutungen.

Ein bekanntes und weit verbreitetes Beispiel hierfür ist das Schlüsselwort using, das so wohl als Direktive wie auch als Anweisung verwendet werden kann:

• Als Direktive dient es zunächst dazu, andere Namensräume bekannt zu machen, so dass die darin enthaltenen Typen ohne Angabe ihres vollqualifizierten Namens genutzt werden können.
• Die Direktive dient zusätzlich jedoch auch der Bildung von Aliasnamen, wobei dies wiederum so wohl für Namensräume wie auch für einzelne Typen möglich ist.
• Als Anweisung schließlich definiert using in Verbindung mit der IDisposable-Schnittstelle einen Gültigkeitsbereich, an dessen Ende automatisch die Dispose-Methode des gekapselten Objekts aufgerufen wird.

Doch nicht nur using ist mit verschiedenen Bedeutungen belegt – ein weiterer Kandidat mit zahlreichen Varianten ist das this-Schlüsselwort:

• In Verbindung mit Konstruktoren dient das this-Schlüsselwort dazu, den Aufruf an einen überladenen Konstruktor der gleichen Klasse weiterzuleiten.
• Mit this ist es zudem möglich, Indexer zu definieren – also Eigenschaften, die über keinen eigenen Namen verfügen, allerdings parametrisiert mit einem Index aufgerufen werden können.
• Seit C# 3.0 dient this als Kennzeichner für Erweiterungsmethoden, indem mit Hilfe dieses Schlüsselworts festgelegt wird, welches Argument dem aufrufenden Objekt entspricht.
• Schließlich dient this – wie bereits in C++ und Java – auch als Referenz auf das eigene Objekt. Auf diese Art kann auf Elemente der Klasse zugegriffen werden, deren Namen durch gleichnamige Parameter ansonsten ausgeblendet und damit nicht zugreifbar wären.

Im Gegensatz zu using, dessen Angabe immer erforderlich ist, kann this gegebenenfalls entfallen: Während seine Verwendung bei der Verkettung von Konstruktoren, Indexern und Erweiterungsmethoden obligatorisch ist, kann die Eigenreferenz entfallen – sofern der Name des betroffenen Elements nicht ausgeblendet wird.

Die Frage lautet allerdings, ob es sinnvoll ist, this in den optionalen Fällen zu streichen. Zunächst scheint es so, schließlich erspart man sich einige Zeichen zu tippen, zu lesen und vermeidet unnötige Redundanz. Auch ReSharper empfiehlt bei Verwendung der Standardeinstellungen, redundante this-Schlüsselwörter zu entfernen.

Neben diesen Vorteilen birgt das Entfernen von this jedoch auch einen essenziellen Nachteil: Es ist nicht mehr auf einen Blick ersichtlich, ob ein Zugriff auf ein Element des aktuellen Objekts stattfindet. So ist bei der Zeile

_foo = new Foo();

nicht klar, ob es sich um eine statisches Feld oder ein Instanzfeld handelt. Wird das Schlüsselwort this jedoch konsequent verwendet, ist auf den ersten Blick eindeutig, dass es sich um ein statisches Feld handelt, ansonsten müsste die Zeile nämlich

this._foo = new Foo();

lauten. Während diese Mehrdeutigkeit bei Feldern noch zu vertreten sein mag, wird es bei Eigenschaften bedeutend schwieriger: So bestehen für die Zeile

Foo.Bar();

bereits drei Möglichkeiten, welcher Aufruf sich dahinter verbirgt: Zum einen könnte Foo eine Eigenschaft sein, an der eine Methode namens Bar aufgerufen wird. Es ist jedoch nicht eindeutig, ob es sich bei der Eigenschaft um eine statische oder eine instanzbehaftete Eigenschaft handelt.

Neben diesen zwei Möglichkeiten könnte es zudem sein, dass Foo gar keine Eigenschaft, sondern eine statische Klasse bezeichnet, die ihrerseits wiederum eine Methode Bar() enthält.

Der Unterschied zwischen einer statischen Eigenschaft und einer statischen Klasse lässt sich ohne weiteres nicht auflösen – zumindest der erste Fall kann aber durch Verwendung von this explizit gemacht werden. Bei der Zeile

this.Foo.Bar();

ist nämlich auf den ersten Blick ersichtlich, dass eine Methode an einer Eigenschaft aufgerufen wird, die instanzbehaftet ist.

Diese Beispiele zeigen, dass die konsequente Verwendung von this durchaus ihren Teil zu einer besseren Verständlichkeit des Quellcodes beitragen kann.

Da Code in der Regel derart geschrieben wird, dass er für die Zukunft wie auch für andere Entwickler gut lesbar ist, kann es durchaus eine vernünftige Entscheidung sein, this generell zu verwenden – insbesondere auch in den redundanten Fällen, um die Semantik des Codes explizit zu machen.

Für welche Variante auch immer ein Entwickler beziehungsweise ein Team sich entscheidet, wichtig ist – wie so oft, wenn es um das Thema Coderichtlinien geht – dass die einmal getroffene Entscheidung konsequent eingehalten wird. Alles andere führt über kurz oder lang zu Missverständnissen.