Antwort.

Hintergrund:

In der klassischen OOP wird Kapselung durch private Felder und Getter/Setter realisiert, was umständlich und nicht "pythonisch" ist. In Python wurde ab Version 2.2 der Dekorator @property eingeführt, der es ermöglicht, auf Getter- und Setter-Methoden wie auf normale Attribute zuzugreifen und so eine saubere Kapselung mit komfortabler Syntax zu erreichen.

Problem:

Ohne Property-Dekoratoren müssen Methoden für den Zugriff und das Setzen von Werten explizit definiert werden (zum Beispiel get_x() und set_x(val)), was den Code weniger lesbar macht und die Benutzer der Klasse nicht vor direktem Zugriff auf interne Daten schützt. Es entstehen Probleme beim Refactoring und der Änderung der internen Logik zur Speicherung oder Berechnung von Werten.

Lösung:

Der Dekorator @property ermöglicht die Definition von Gettern, Settern und Deletoren mit einer einheitlichen Syntax. Das sieht knapp und bequem aus, kapselt die Implementierungsdetails und erlaubt es, die Berechnung von Eigenschaften transparent zu ändern, ohne die Schnittstelle der Klasse zu verletzen.

Beispielcode:

class Temperature:
    def __init__(self, celsius):
        self._celsius = celsius

    @property
    def celsius(self):
        return self._celsius

    @celsius.setter
    def celsius(self, value):
        if value < -273.15:
            raise ValueError("Temperatur unter -273.15°C ist nicht möglich!")
        self._celsius = value

Wesentliche Merkmale:

Der Dekorator @property ermöglicht den Zugriff auf Methoden wie auf normale Attribute.
Leicht zu ergänzende Logik für Validierung oder Caching.
Änderung der Logik ohne Wechsel der Schnittstelle — Benutzer der Klasse bemerken keine Änderungen.

Hinterhältige Fragen.

Kann man eine Eigenschaft nur lesbar, aber nicht schreibbar/löschbar machen?

Ja, wenn man nur die Methode mit dem Dekorator @property ohne Setter und Deleter definiert, ist die Eigenschaft nur lesbar.

class Sample:
    @property
    def value(self):
        return 42

Was passiert, wenn der Name der property mit einem privaten Attribut übereinstimmt?

Normalerweise wird die property als "Zwischenschicht" zu einem privaten Attribut verwendet, dessen Name mit einem Unterstrich beginnt (zum Beispiel _x). Eine solche Übereinstimmung sollte vermieden werden, da sonst ein rekursiver Aufruf entsteht:

class Bad:
    @property
    def x(self):
        return self.x  # Unendliche Rekursion

Kann man eine property nur für die Klasse festlegen?

Nein, der Standard @property funktioniert mit Instanzen der Klasse. Für die Erstellung einer Klassenproperty sollten externe Muster oder spezielle Bibliotheken verwendet werden (@classmethod zusammen mit property funktioniert nicht direkt).

Typische Fehler und Anti-Pattern

Falsche Benennung von Attributen (zum Beispiel die Duplizierung des Namens der property und des internen Feldes).
Falsch implementierter Setter führt zu rekursiven Aufrufen.
Missbrauch von property für Eigenschaften, die keine Berechnung/Validierung erfordern.

Beispiel aus dem Leben

Negativer Fall

Ein Entwickler greift direkt auf das Klassenfeld (self.celsius) zu und nicht über die property. Später wird eine Validierung hinzugefügt, aber die Verbraucher der Klasse können immer noch direkt das private Attribut modifizieren und die Überprüfungen umgehen.

Vorteile:

Einfach und schnell zu arbeiten, solange keine komplexe Logik vorhanden ist.

Nachteile:

Kapselung wird verletzt, es kann leicht zu einem inkorrekten Zustand des Objekts kommen, Verwirrung entsteht.

Positiver Fall

Die Verwendung von property und die Verbergung des internen Attributs über _celsius. Validierung, Caching und Logik zentralisieren sich innerhalb der property.