Properties (Eigenschaften) in C#

1. Einführung

Lass uns mit den Problemen starten, die beim direkten Verwenden von Feldern auftreten. Wenn du ein Feld als public deklarierst, kann es sofort und direkt von überall im Programm geändert werden:

public class Dog
{
    public string Name;
}

Dog dog = new Dog();
dog.Name = ""; // O_o ... das ist wie "Name des Hundes = leerer String"!

Der User kann dem Feld Name total verrückte Werte zuweisen, sogar solche, die für deinen Anwendungsfall keinen Sinn machen: einen leeren String, einen zu langen Namen oder sogar null. Das ist, als würdest du jemandem, der deinen neuen IKEA-Schrank zusammenbaut, vollen Zugang zur ganzen Holzfabrik geben.

Zur Erinnerung: Kapselung bedeutet, dass das Objekt seine Daten selbst kontrolliert. Wir vertrauen nicht jedem dahergelaufenen Code unsere Interna an, sondern geben spezielle "Türen" — Properties (Properties), durch die der Zugriff aufs Feld läuft, aber mit der Möglichkeit zu prüfen, zu loggen, zu modifizieren oder sonstwie auf Änderungen zu reagieren.

2. Definition und Syntax

Property ist ein spezielles Klassenmitglied, das fast wie ein Feld aussieht, aber unter der Haube eigentlich ein Paar spezieller Methoden ist: getter (Wert holen) und setter (Wert setzen). Mit einer Property kannst du:

• Lesen/Schreiben von Daten erlauben (oder verbieten);
• Validierung oder Logik beim Zugriff auf Daten hinzufügen;
• Das interne Feld verstecken und den Wert sogar woanders speichern.

Eine Property wird fast wie ein Feld deklariert, nur mit geschweiften Klammern und den Schlüsselwörtern get und set darin.

[Zugriffsmodifizierer] Typ PropertyName
{
    get { ... }
    set { ... }
}

Hier ein Beispiel für unsere Dog-Klasse:

public class Dog
{
    private string _name; // internes Feld (private!)

    public string Name
    {
        get { return _name; }  // "Getter": Name holen
        set { _name = value; } // "Setter": Name setzen
    }
}

Hinweis: Der Unterstrich wird normalerweise für private Felder (_name) verwendet. Das ist C#-Style-Standard.

3. Wie Properties funktionieren

Eine Property ist so eine Art „Wächter“, der zwischen den internen Daten des Objekts und der Außenwelt steht. Beispiel:

Dog dog = new Dog();
dog.Name = "Sharik";
Console.WriteLine(dog.Name);

Erklärung:

• Wenn das Programm bei dog.Name = "Sharik"; ankommt, wird der set-Methode der Property aufgerufen, und du kannst dort jede beliebige Prüfung einbauen (z.B. dass der Name nicht leer ist).
• Bei Console.WriteLine(dog.Name); wird die get-Methode aufgerufen, die einfach den aktuellen Wert zurückgibt oder, falls nötig, etwas Dynamisches berechnet.

Sieht aus wie ein normales Feld, aber in Wirklichkeit hast du alles unter Kontrolle!

4. Warum Properties "Best Practice" sind

Meistens geben wir keinen direkten Zugriff auf interne Felder eines Objekts. Selbst wenn es gerade keine Prüfungen braucht, ist es eine super Angewohnheit, Daten immer in Properties zu packen – das rettet dich, wenn sich die Regeln mal ändern.

Beispiel für "Validierung" beim Setzen:

public class Dog
{
    private string _name;

    public string Name
    {
        get { return _name; }
        set
        {
            if (string.IsNullOrWhiteSpace(value))
            {
                throw new ArgumentException("Der Name des Hundes darf nicht leer sein!");
            }
            _name = value;
        }
    }
}

Jetzt passiert Folgendes:

dog.Name = ""; // Löst eine Exception aus!

… schützt unser Objekt vor unsinnigen Werten.

5. Properties: Nur lesbar, nur schreibbar und normale

Manchmal soll man nur den Wert lesen dürfen (z.B. das Geburtsjahr des Hundes, das sich nicht ändern darf), oder umgekehrt – nur setzen (selten, aber vielleicht willst du mal was Mysteriöses machen).

• Nur lesbar: nur get schreiben, set weglassen.
• Nur schreibbar: nur set schreiben, get weglassen.

Beispiele:

public class Dog
{
    private int _birthYear = 2018;

    // Nur lesbar
    public int BirthYear
    {
        get { return _birthYear; }
    }

    // Nur schreibbar (kommt sehr selten vor)
    public string Secret
    {
        set { /* mach was mit value */ }
    }
}

6. Properties vs. Felder

public string Name;

public string Name { get; set; }

Illustration: Wie eine Property arbeitet

sequenceDiagram
participant User as Benutzer des Objekts
participant Dog as Objekt Dog
participant Field as Privates Feld _name

User->>Dog: dog.Name = "Ryzhik"
Dog->>Dog: set Name("Ryzhik")
Dog->>Field: _name = "Ryzhik"

User->>Dog: print(dog.Name)
Dog->>Dog: get Name()
Dog->>Field: liest _name
Dog->>User: gibt "Ryzhik" zurück

7. Typische Fehler und Besonderheiten

Schauen wir uns an, wo hier Fallen lauern können.

Ein häufiger Fehler ist, Felder und Properties zu verwechseln und versehentlich private Daten nach außen zu öffnen:

public string name; // Das ist ein Feld! Überall sichtbar, gefährlich!

Besser so:

private string _name;
public string Name
{
    get { return _name; }
    set { _name = value; }
}

Statische Properties gibt es auch, um Werte zu speichern, die für alle Objekte gleich sind. Aber benutze sie mit Vorsicht.

Fun Fact: Wenn eine Property nur get hat und keinen Konstruktor, kann sie überhaupt nicht geändert werden – das nennt man immutable property und das wird in modernen Design-Ansätzen oft genutzt (wir kommen darauf nochmal ausführlich zurück in den Vorlesungen zu record und Unveränderlichkeit von Daten).