Wirbel um Visual Studio 2010: über C# 4.0 und agile Methoden im Team Foundation Server

Inhaltsverzeichnis

Mit Visual Studio 2010 und .NET 4.0 halten auch eine neue Version von C# und die Unterstützung agiler Methoden durch den Team Foundation Server Einzug in die Programmierwelt. Was auf den ersten Blick löblich erscheint, mag für den einen oder anderen Entwickler aber nicht umfassend genug umgesetzt sein.

In jeder C#-Version hat Microsoft einen Schwerpunkt gesetzt: War das Ziel in C# 1.0 eine konsistent objektorientierte Sprache, stand die Version 2.0 im Zeichen generischer Datentypen. Besonders auffällig war die Fokussierung auf einen Aspekt in C# 3.0: Mit Ausnahme der automatisch implementierten Eigenschaften hat wohl kein einziges Sprachmerkmal Einzug in C# 3.0 gehalten, das nicht eine notwendige Vorbedingung für LINQ darstellt.

Im Rahmen von .NET 4.0 beschert Microsoft der Entwicklergemeinde nun C# 4.0. Die neue Version setzt den Fokus auf eine verbesserte Interoperabilität zu funktionalen und dynamischen Sprachen sowie eine überarbeitete Kompatibilität zu COM. Vergleicht man sie mit den Vorgängern, fällt auf, dass sich die Zahl der Neuerungen in Grenzen hält. Lediglich vier neue Funktionen respektive Sprachmerkmale bietet die Sprache, nämlich erstens optionale sowie zweitens benannte Parameter, drittens dynamische Datentypen und schließlich Ko- beziehungsweise Kontravarianz für generische Datentypen.

Optionale und benannte Parameter

Optionale Parameter ermöglichen es, Parameter einer Methode mit Standardwerten zu versehen und die Angabe der jeweiligen Parameter dadurch als optional zu kennzeichnen: Wird der Parameter – ganz klassisch – explizit angegeben, verwendet man den entsprechenden Wert; wenn nicht, nutzt man implizit den in der Methodendefinition angegebenen Standardwert.

Das Sprachmerkmal wirkt auf den ersten Blick ausgesprochen nützlich, entfällt damit die Notwendigkeit, unterschiedliche Varianten einer Methode aufwendig überladen zu müssen. Da zudem die Syntax für den Aufrufer beim Verwenden optionaler Parameter der Syntax einer überladenen Methode entspricht, scheint die Welt in Ordnung zu sein – bis man feststellt, dass optionale Parameter eine andere Semantik aufweisen als überladene Methoden.

In der Praxis sollte der Entwickler optionale Parameter daher nur im Rahmen der COM-Interoperabilität verwenden, für alle übrigen Fälle sind sie in der Regel untauglich. Ähnlich verhält es sich mit benannten Parametern: Da sie sich nur in Kombination mit optionalen Parametern sinnvoll einsetzen lassen, erübrigt sich ihr regulärer Einsatz in der Praxis.

Trotz der Mängel für den Alltagsgebrauch stellen beide Sprachmerkmale bei der Verwendung von COM eine drastische Vereinfachung dar. Wer beispielsweise jemals Microsoft Office mit den Visual Studio Tools für Office (VSTO) anbinden musste, kennt das Problem der zahlreichen "ref missing"-Parameter und wird die Möglichkeit, nur die tatsächlich benötigten Parameter angeben zu können, schätzen.

Dynamische Datentypen

Dynamische Datentypen – und hierbei insbesondere die Verwendung des Schlüsselworts dynamic – sind ein weiteres Sprachmerkmal, das auf den ersten Blick zwar ausgesprochen hilfreich erscheint, dessen Alltagstauglichkeit bei näherem Hinsehen jedoch deutliche Fragen aufwirft. Die Idee hinter dynamischen Datentypen ist, Referenzen deklarieren zu können, deren Datentyp sich erst zur Laufzeit ergibt – und der sich gegebenenfalls sogar während der Ausführung ändern kann.

Erforderlich ist das Sprachmerkmal für die Integration von C# mit dynamischen und funktionalen Sprachen: Es ist dort beispielsweise möglich, eine Methode zu definieren, die – abhängig vom Kontext – einen Int32- oder einen DateTime-Typ zurückgibt. Um die Rückgabewerte solcher Methoden in C# überhaupt verarbeiten zu können, müsste entweder auf den Datentyp object und Reflection oder auf dynamische Datentypen zurückgegriffen werden.

Im Kern arbeiten dynamische Datentypen in C# 4.0 ebenfalls mit object und Reflection – sie bieten lediglich einen einfachen und komfortablen Wrapper, stellen letztlich also "syntactic sugar" dar. Daraus folgt, dass alle Nachteile, die beim Verwenden einer Instanz mit Reflection bestehen, auch beim Einsatz von dynamischen Datentypen auftreten – von Syntaxfehlern bis hin zur geringen Performance.

Daher sollte man dynamische Datentypen nur einsetzen, wenn keine andere Lösung zur Wahl steht und ansonsten auf den Datentyp object und Reflection zurückgreifen. Durch die einfache Nutzbarkeit der bislang genannten Sprachmerkmale ist allerdings zu erwarten, dass sie sich in größerem Stil verbreiten werden.

Ko- und Kontravarianz von generischen Datentypen

Das vierte Sprachmerkmal stellt eine Ausnahme dar – denn die Sprachentwickler haben es weder für die Sprach- noch für die COM-Interoperabilität eingeführt, sondern es stellt eine von vielen Programmierern schmerzlich vermisste Funktion zur Verfügung: die Ko- und Kontravarianz von generischen Datentypen.

Obwohl der Datentyp string in .NET von object abgeleitet und somit in diesen Typ konvertierbar ist, gilt das Gleiche nicht für generische Datentypen: Eine List<string> erbt nicht von
List<object> und ist auch nicht direkt in eine solche konvertierbar – das galt bis C# 3.0.

Mit C# 4.0 führt Microsoft diese Kompatibilität ein – allerdings nicht pauschal für alle generischen Datentypen, sondern nur für generische Schnittstellen und Delegaten, wobei IEnumerable<T> wohl der häufigste Anwendungsfall sein dürfte. Auch bei der Implementierung eigener generischer Datentypen lässt sich die Option, sie zu konvertieren, explizit freischalten, wobei sogar zwischen Lese- und Schreibzugriffen zu unterscheiden ist.

Da das Sprachmerkmal schwieriger zu verstehen ist als die drei zuvor genannten, ist von der Annahme auszugehen, dass es nicht so viel Verbreitung erreichen wird wie die anderen – obwohl es von seiner Alltagstauglichkeit her deutlich geeigneter für eine weite Verbreitung wäre.

Insgesamt hinterlässt C# 4.0 gemischte Gefühle: So schön die Neuerungen einerseits für die sind, die sie für COM und die Interoperabilität mit funktionalen Sprachen nutzen können, so viel Gefahrenpotenzial bergen sie zugleich. Zudem enthält die neue Version für alle übrigen Entwickler nur Ko- und Kontravarianz von generischen Datentypen als neues Sprachmerkmal. Ob die Erweiterungen einen Sprung der Hauptversionsnummer rechtfertigen, ist daher zumindest fraglich.