Kategorie: Softwareentwicklung

Partielle Klassen 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
010203
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.

Objekt- und Auflistungsinitialisierer in C# 👍 👎

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)
010203
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.

Enumerationen in C# 👍 👎

Während man in anderen Programmiersprachen (wie beispielsweise PHP) eine Sammlung von Konstanten bemühen muss, um zumindest so etwas ähnliches wie einen Aufzählungstypen zu definieren, bietet uns C# hierfür eine komfortable und zugleich typsichere Lösung mittels enum an.

Häufig finden derartige Aufzählungen im Rahmen von Optionen für Methodenaufrufe Verwendung; auch im .NET-Framework begegnet ihr diesen sehr häufig (z. B. bei Dateioperationen mit der Enumeration FileMode). Als Beispiel soll hier das Recht eines Benutzers dienen. Zuerst definieren wir dazu eine entsprechende Enumeration:
Enumeration "Permission" mit den Rechten "Lesen", "Schreiben" und "Löschen"
0102030405
public enum Permission {    Read,    Write,    Delete}
Als nächstes erstellen wir eine (sehr minimalistische) Benutzer-Klasse, welche eine zu unserer Rechte-Enumeration kompatible Eigenschaft besitzt:
Klasse "User" mit Eigenschaft für Benutzerrecht
010203040506
public class User {    public Permission UserPermission {        get;        set;    }}
Jetzt können wir auch schon eine Benutzer-Instanz erzeugen und ein Recht zuweisen, beispielsweise "Lesen":
Benutzer mit Leserecht erzeugen
010203
User du = new User() {    UserPermission = Permission.Read};
Das Prinzip entspricht soweit grundsätzlich also dem Vorgehen wie bei jedem anderen Datentypen (→ allgemeinere Informationen) auch. Insbesondere können wir der Eigenschaft UserPermission z. B. nicht versehentlich einen Wert einer Aufzählung "Farbe" oder "Geschlecht" zuweisen. Nun wäre es noch praktisch, wenn wir auch auf ein spezifisches Benutzerrecht prüfen könnten – also implementieren wir eine entsprechende Methode in der Benutzer-Klasse:
Methode zur Rechteprüfung in "User"
010203
public bool CheckPermission(Permission permission) {    return (this.UserPermission == permission);}
Die Verwendung gestaltet sich nun denkbar einfach (ich schreibe es der Vollständigkeit wegen dennoch auf Smiley: tongue_out):
Rechteprüfung
0102030405
if(du.CheckPermission(Permission.Write)) {    // Recht vorhanden} else {    // Recht NICHT vorhanden}
Soweit können wir glaube ich zufrieden sein. Einen kleinen Schönheitsfehler gibt es jedoch: Wenn wir voraussetzen, dass ein Benutzer mit reinen Schreibrechten noch nichts löschen darf, so müssten wir ihm zwei Rechte zuweisen, wenn er es doch können soll. Wir könnten also eine Rechteliste führen – oder wir bedienen uns der Bitarithmetik und des Flags-Attributs (→ weitere Details zur Verwendung) und bringen beide Rechte in nur einem Feld unter.

Dazu passen wir zuerst einmal unsere Aufzählung an, da wir zu diesem Zwecke Zweierpotenzen als Werte benötigen und geben auch gleich das Attribut mit an. Der späteren Bequemlichkeit wegen, erstellen wir auch noch einen weiteren Wert ReadWrite, welchen wir mit einem bitweisen ODER aus Read und Write definieren:
Enumeration "Permission" mit Attribut und eigenen Werten versehen, sowie Erweiterung um "ReadWrite"
01020304050607
[Flags]public enum Permission {    Read = 1,    Write = 2,    Delete = 4,    ReadWrite = (Read | Write)}
Darüber hinaus müssen wir unsere Prüfmethode geringfügig anpassen:
Methode zur Rechteprüfung in "User" erweitern
010203
public bool CheckPermission(Permission permission) {    return ((this.UserPermission & permission) == permission);}
Nun können wir wieder ein Objekt erzeugen und erhalten die erwarteten Ergebnisse:
Benutzer mit Rechten erzeugen und prüfen
01020304050607080910111213
  // Benutzer mit Lese- und Schreibrecht erzeugenUser du = new User() {    UserPermission = (Permission.Read | Permission.Write)      // – oder auch -    UserPermission = Permission.ReadWrite};
// Rechte prüfen (einige Beispiele)du.CheckPermission(Permission.Read); // truedu.CheckPermission(Permission.Write); // truedu.CheckPermission(Permission.Delete); // falsedu.CheckPermission(Permission.ReadWrite); // truedu.CheckPermission(Permission.Read | Permission.Delete); // false
Eine derartige Vorgehensweise findet auch innerhalb des .NET-Frameworks Verwendung, z. B. bei Dateioperationen mit der Enumeration FileAccess.

Eigenschaften in C# 👍 👎

C# besitzt eine – meiner Meinung nach – äußerst elegante Implementierung für Akzessoren. Während es beispielsweise in Java üblich ist, nach dem Muster getEigenschaft() (und setEigenschaft(…)) zu verfahren, kombiniert C# Felder und Zugriffsmethoden zu sog. Properties.

Dies stellt einerseits die Kapselung der internen Daten sicher, vermeidet darüber hinaus jedoch eine Sammlung dutzender Zugiffsmethoden neben den eigentlichen Operationen einer Klasse. Sollte man lediglich "Standardzugriff" benötigen, wird einem dies besonders einfach gemacht – doch dazu später noch etwas mehr.

Als kleines Beispiel dazu wollen wir eine Klasse Person entwickeln, welche den Vor- und Nachnamen einer Person aufnehmen kann:
Klasse "Person" mit Eigenschaften (manuelle Implementierung)
010203040506070809101112131415161718192021
public class Person {    private string firstName;    public string FirstName {        get {            return this.firstName;        }        set {            this.firstName = value;        }    }
private string lastName; public string LastName { get { return this.lastName; } set { this.lastName = value; } }}
Wie man sieht, erstellen wir dazu private Felder für die Daten und definieren dann die Eigenschaft (per Konvention mit einem Großbuchstaben beginnend) mit den entsprechenden Zugriffsmethoden (get und set). Der Parameter value wird implizit zur Verfügung gestellt und enthält den jeweils zugewiesenen Wert.

Der Zugriff auf diese Daten ist nun ganz einfach möglich:
Zugriff auf Eigenschaften der Klasse "Person"
0102030405060708091011
  // Zuweisung nach ObjekterzeugungPerson ich = new Person();
ich.FirstName = "Holger"; // Abfrage liefert "Holger"ich.LastName = "Stehle"; // Abfrage liefert "Stehle"
// Zuweisung per ObjektinitialisierungPerson ich = new Person() {
FirstName = "Holger", LastName = "Stehle"}; /* Abfrage-Resultate wie oben */
Innerhalb der Zugriffsmethoden kann beispielsweise Validierungslogik untergebracht werden. Das bloße Zuweisen und Abfragen ohne besondere zusätzliche Arbeit ist jedoch auch noch deutlich kompakter möglich – C# implementiert die Zugriffsmethoden dann automatisch. Sogar die interne Eigenschaft kann man sich sparen:
Klasse "Person" mit Eigenschaften (automatische Implementierung)
0102030405060708091011
public class Person {    public string FirstName {        get;        set;    }
public string LastName { get; set; }}
Das Verhalten ist nun wie in unserer vorherigen Klasse, die Verwendung entsprechend ebenfalls identisch. Eine feinere Abstimmung der Zugriffsebenen ist ebenfalls möglich. Weitere Details zur Verwendung finden sich im MSDN.

Ressourcen freigeben in C# 👍 👎

Dank verwaltetem Code und automatischer Speicherbereinigung muss man sich bei C# zumeist nicht explizit darum kümmern, angeforderte Ressourcen wieder freizugeben. An manchen Stellen kann dies jedoch notwendig sein: Dies ist beispielsweise der Fall, wenn nicht verwaltete oder externe Ressourcen (z. B. Dateien, Datenbanken) involviert sind.

Zur Freigabe von Ressourcen sollte die entsprechende Dispose()-Methode aufgerufen werden, welche Objekte zur Verfügung stellen, welche IDisposable implementieren. Dies kann beispielsweise wie folgt passieren:
Ressourcen explizit freigeben
0102030405060708091011
Class obj = new Class();
try { /** * Anwendungs-Code **/} finally { if(obj != null) { obj.Dispose(); }}
Es gibt jedoch noch eine elegantere Variante, und zwar mit Hilfe der using-Anweisung:
Ressourcen implizit freigeben (empfohlen)
0102030405
using(Class obj = new Class()) {    /**     * Anwendungs-Code    **/}
Durch dieses Vorgehen werden die Ressourcen automatisch nach Verlassen des Gültigkeitsbereichs freigegeben; dazu wird im Hintergrund folgender Code generiert:
Generierter Code zur Freigabe der Ressource
01020304050607080910111213
{    Class obj = new Class();
try { /** * Anwendungs-Code **/ } finally { if(obj != null) { ((IDisposable) obj).Dispose(); } }}
Zu beachten gilt, dass der using-Block – wie bereits durch die umschließenden geschweiften Klammern zu sehen – einen eigenen Gültigkeitsbereich darstellt, was demnach bei Variablendeklaration und -verwendung berücksichtigt werden muss.

Projektverweise

Kategorien / Archiv  |  Übersicht RSS-Feed

Schlagworte

Suche