Blog | Holger Stehle

Partial Classes in C# 👍 👎

C# unterstützt sogenannte partielle Klassen, welche es ermöglichen, eine Klasse auf verschiedene Dateien verteilt zu definieren. Diese werden bei der Kompilierung zu einer einzelnen Klasse zusammengeführt, so als wäre sie wie eine "normale" Klasse in einer Datei definiert worden. Insbesondere ist also auch dateiübergreifend Zugriff auf private Mitglieder (Eigenschaften, Methoden etc.) einer Klasse möglich.

Wir wollen dies wie üblich an einem (kleinen) Beispiel konkretisieren und legen dazu einfach die Eigenschaften und Methoden einer Klasse in zwei verschiedenen Dateien ab:

Klasse "Person" in Datei "Person.cs"

01020304050607080910111213141516

public partial class Person {    public Person(string firstName, string lastName) {        this.FirstName = firstName;        this.LastName = lastName;    }
      // Partner liefern    public Person GetPartner() {        // z. B. aus Datenbank auslesen    }
      // Kinder liefern    public List<Person> GetChildren() {        // z. B. aus Datenbank auslesen    }}

Klasse "Person" in Datei "Person.Properties.cs"

01020304050607080910111213141516

public partial class Person {    public string FirstName {        get;        set;    }
    public string LastName {        get;        set;    }
    public int Age {        get;        set;    }}

Zugegeben: Es ist fraglich, ob dieses Vorgehen – insbesondere in diesem trivialen Beispiel – überhaupt sinnvoll ist. Andererseits ergibt sich für den Aufrufer/Verwender der Klasse keinerlei Unterschied zur Definition in einer Datei, da letztlich eine einzige Klasse herauskommt. Insofern ist dem Entwickler (bzw. den Richtlinien des Teams) überlassen, ob und ggf. wie man damit umgehen möchte. Die Verwendung erfolgt jedenfalls ganz wie gewohnt:

Anwendung der partiell definierten Klasse

Person ich = new Person("Holger", "Stehle") {    Age = 24};

Ein großer Vorteil ergibt sich jedoch bei der Verwendung von Code-Generatoren. Der generierte Code definiert dabei partielle Klassen. Diese können nun in einer eigenen Datei erweitert werden, ohne Gefahr zu laufen, bei einer neuen automatischen Codegenerierung alle Anpassungen zu verlieren. Visual Studio selbst setzt auf derartiges Vorgehen z. B. im Zusammenhang mit ADO.NET Entity Framework oder grafischen Benutzeroberflächen (vgl. "*.Designer.cs"-Dateien).

Andere Einsatzmöglichkeiten wären die übersichtliche Arbeit verschiedener Entwickler an einer umfangreicheren Klasse oder das Anbieten einer Anwendung mit verschiedenen Ausprägungen der Funktionalität einer Klasse, indem nur spezifische Dateien der partiellen Klasse kompiliert werden.

Mit der praktischen kleinen Erweiterung NestIn für Visual Studio (nicht Express) könnt ihr im Übrigen mit wenigen Mausklicks auch dafür sorgen, dass die Dateien wie aus der Entwicklungsumgebung bekannt verschachtelt dargestellt werden, was meiner Ansicht nach deutlich zur Übersicht beiträgt.

Gallery 👍 👎

I have started a small Gallery, which is supposed to be sporadical extended.

Tags and Search 👍 👎

As of now, you can find tags for individual blog postings.

Furthermore, the postings can be searched easily.

Object and Collection Initialisers 👍 👎

Diese Technik habe ich in meinen Beiträgen bereits mehrfach verwendet und möchte sie daher für diejenigen, denen sie nicht geläufig ist, kurz erläutern.

Oftmals besitzt man Klassen mit zahlreichen Eigenschaften, für die man direkt nach Aufruf des Konstruktors diverse Werte setzen möchte. Es dient dabei meist eher weniger der Übersicht, all diese Eigenschaften bereits im Konstruktor zur Verfügung zu stellen, sofern sie für die Erzeugung des Objektes nicht zwingend erforderlich sind, bzw. bereits entsprechende Standardwerte hierfür besitzen. Für unsere folgenden Beispiele verwenden wir der Übersicht wegen folgende eher überschaubare Klasse:

Klasse "Person"

010203040506070809101112131415161718192021222324

public class Person {    public string FirstName {        get;        set;    }
    public string LastName {        get;        set;    }
    public int Age {        get;        set;    }

    public Person() {  }
    public Person(string firstName, string lastName) {        this.FirstName = firstName;        this.LastName = lastName;    }}

Davon können wir nun Objekte instanziieren und die Eigenschaften per Konstruktor oder explizit setzen:

Objekt instanziieren und Eigenschaften explizit setzen

01020304050607080910

  // Eigenschaften explizit definierenPerson ich = new Person();
ich.FirstName = "Holger";ich.LastName = "Stehle";ich.Age = 24;
  // Eigenschaften per Konstruktor und explizit definierenPerson ich = new Person("Holger", "Stehle");ich.Age = 24;

Es gibt jedoch noch eine andere – wie ich finde sehr komfortable und vor allem übersichtliche – Variante dies zu lösen, und hier kommen die Objektinitalisierer zum Einsatz, die sich im Übrigen auch mit dem Konstruktor kombinieren lassen:

Objekt instanziieren und Eigenschaften per Objektinitialisierer setzen

0102030405060708091011

  // Konstruktor nicht belegenPerson ich = new Person() {    FirstName = "Holger",    LastName = "Stehle",    Age = 24};
  // Konstruktor belegenPerson ich = new Person("Holger", "Stehle") {    Age = 24};

Eine erweiterte Möglichkeit bieten nun noch die Auflistungsinitialisierer, indem Sie das komfortable Hinzufügen von Werten zu Containern erlauben, welche IEnumerable implementieren. Dies erspart das mehrfache Aufrufen der entsprechenden Add(…)-Methoden zur Initialisierung. Für die folgenden Beispiele verwenden wir dazu generische Listen, welche einmal Zeichenketten und außerdem Objekte unserer Klasse aufnehmen können:

Auflistungsinitialisierung (einfache Zeichenketten)

List<string> animalList = new List<string>() {    "Hund", "Katze"};

Auflistungsinitialisierung (inkl. Objektinitalisierung)

01020304050607080910111213

List<Person> personList = new List<Person>() {    new Person() {        FirstName = "David",        LastName = "Hilbert"    },    new Person("Georg", "Cantor"),    new Person("Bernhard", "Riemann"),    new Person("Leonhard", "Euler"),    new Person() {        FirstName = "Johann",        LastName = "Bernoulli"    }};

Wie im letzten Beispiel ersichtlich, ist also innerhalb eines Auflistungsinitialisierers wiederum die Verwendung von Objektinitalisierern möglich. Ein paar weitere Beispiele finden sich auch noch im MSDN.

Notation of formal Expressions 👍 👎

a + b ist ein Term, wobei a und b als Summanden bezeichnet werden. Das sollte soweit jedem Leser dieses Blogs klar sein – mit Grundschulmathematik soll es nun aber gar nicht weitergehen, wir benötigen nur eine gemeinsame Grundlage für den weiteren Teil des Artikels. Smiley: grinning

Einen Bestandteil haben wir bisher jedoch gar nicht näher betrachtet: Das beinahe selbstverständliche Symbol der Addition, das +. Dabei ist das gar nicht so uninteressant. Was genau ist das eigentlich? Nun, auf jeden Fall wird es als Operator bezeichnet. Diese Schreibweise ist uns so vertraut, dass sich die meisten bisher wahrscheinlich gar keine Gedanken zu den Hintergründen einer solchen Schreibweise gemacht haben – und wir auch andere ganz selbstverständlich verwenden.

Tatsächlich handelt es sich nämlich um den in sogenannter Infixnotation geschriebenen Aufruf der Funktion +(a,b); der Name der Funktion lautet also + und Funktionen dieser Darstellung werden üblicherweise in Präfixnotation geschrieben. Dies ist einem aus der Mathematik bei Funktionen wie sin und cos geläufig und selbstverständlich auch als Entwickler der meisten Programmiersprachen und sogar bei Konsoleneingaben.

Präfixnotation findet in der Mathematik meist bei unären Operationen Anwendung, wohingegen bei binären Operationen für gewöhnlich die Infixnotation zum Einsatz kommt. Mehrstellige Operationen werden (auch) in einfacher Funktionsschreibweise notiert.

Bei in Infixnotation geschriebenen Ausdrücken ist unbedingt die Operatorpräzedenz (und ggf. Operatorassoziativität) zu berücksichtigen. Dazu gehört auch der den meisten Lesern sicherlich bekannte Spruch "Punkt vor Strich": Manche Operationen müssen vor anderen ausgewertet werden, um das Ergebnis eindeutig zu halten; im Allgemeinen gilt beispielsweise:

(a + b) * c ≠ a + (b * c)

Wie dadurch bereits ersichtlich und hoffentlich bekannt, lässt sich eine bestimmte Rangfolge mit Klammerung auch erzwingen. Üblicherweise gilt ohne nähere Spezifikation folgende Rangfolge bei einfachen Rechnungen:

Klammerung
Potenzierung
Multiplikation, Division ("Punktrechnung")
Addition, Subtraktion ("Strichrechnung")

Auch Programmiersprachen (z. B. C#, PHP) besitzen eine solche Rangfolge und unterscheiden sich teilweise.

Um aber noch einmal auf unsere Feststellung der unterschiedlichen Schreibweisen einzugehen: Tatsächlich ist dieses Problem nämlich der Infixnotation geschuldet; Präfixnotation (im Übrigen auch die umgekehrte Variante, die Postfixnotation) kann nämlich klammerfrei erfolgen und ist ganz einfach – wenn auch für die meisten sicherlich eher etwas ungewohnt – auf unser Beispiel der Addition übertragbar:

Addition mit Symbol und Präfixnotation

+ a b

Auch "komplexere" (na ja …) Anwendungen stellen kein Problem dar:

Vergleich von Infix- und Präfixnotation

0102030405

  // Infixnotation(a + b) * (c – d)
  // Präfixnotation* + a b – c d

Wie man sieht, können hier die Klammern entfallen und man erhält dennoch das erwartete Ergebnis. Diese Darstellungsform vereinfacht im Übrigen das automatisierte Verarbeiten erheblich.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
16 17 18 19 20 21 22 23 24 25 26 27 28 29

Project links

BitStadt – Stadtportal
Berlin · Hamburg · Amsterdam
CCC – Fahrplan
Schedules for the CCCongress

Categories / Archive | Übersicht

General (15)
Society (5)
Projects (12)
Software development (94)
Technics (10)
Theory (9)

PHP functions in C# (136)
Dictionary (257)