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.