Antwoord.

Achtergrond:

In de klassieke OOP wordt encapsulatie gerealiseerd door middel van privévelden en getters/setters, wat omslachtig is en niet "Pythonic". In Python werd vanaf versie 2.2 de decorator @property geïntroduceerd, waarmee men getters en setters kan aanspreken als gewone attributen, wat een goede encapsulatie met handige syntaxis mogelijk maakt.

Probleem:

Zonder property decorators moet men expliciet methoden definiëren voor toegang tot en instelling van waarden (bijv. get_x() en set_x(val)), wat de leesbaarheid van de code vermindert en gebruikers van de klasse niet beschermt tegen directe toegang tot interne gegevens. Dit leidt tot problemen bij refactoren en wijzigingen in de interne logica van opslag of berekening van waarden.

Oplossing:

De decorator @property stelt je in staat om getters, setters en deleters te definiëren met behulp van een enkele syntaxis. Dit ziet er beknopt, handig uit, encapsuleert implementatiedetails en maakt het mogelijk om de methode van eigenschapberekening transparant te wijzigen zonder de interface van de klasse te verstoren.

Codevoorbeeld:

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("Temperatuur onder -273.15°C is niet mogelijk!")
        self._celsius = value

Belangrijkste kenmerken:

De decorator @property maakt het mogelijk om methoden aan te spreken als gewone attributen.
Het is eenvoudig om validatielogica of caching toe te voegen.
Wijziging van logica zonder interface verandering — gebruikers van de klasse merken geen veranderingen op.

Misleidende vragen.

Is het mogelijk om een eigenschap alleen-lezen te maken, zonder schrijf- of verwijderrechten?

Ja, als je alleen de methode met de decorator @property definieert zonder setter en deleter, zal de eigenschap alleen-lezen zijn.

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

Wat gebeurt er als de naam van de property overeenkomt met een privéattribuut?

Normaal gesproken wordt property gebruikt als een "tussenlaag" voor een privéattribuut, waarvan de naam met een underscore begint (bijvoorbeeld _x). Dergelijke overeenkomsten moeten worden vermeden, anders ontstaat er een recursieve oproep:

class Bad:
    @property
    def x(self):
        return self.x  # Eindeloze recursie

Is het mogelijk om property alleen voor de klasse aan te wijzen?

Nee, de standaard @property werkt met instanties van de klasse. Voor het maken van een class property moet je gebruik maken van externe patronen of speciale bibliotheken (@classmethod werkt niet direct samen met property).

Veelvoorkomende fouten en anti-patronen

Onjuiste naamgeving van attributen (bijvoorbeeld duplicatie van de naam van de property en het interne veld).
Onjuist geïmplementeerde setter leidt tot recursieve oproepen.
Misbruik van property voor eigenschappen die geen berekening/validatie vereisen.

Voorbeeld uit het leven

Negatief geval

Een ontwikkelaar spreekt rechtstreeks het klasseveld aan (self.celsius), in plaats van via property. Later wordt er validatie toegevoegd, maar de consumenten van de klasse kunnen nog steeds het privéattribuut rechtstreeks aanpassen en de controles omzeilen.

Voordelen:

Eenvoudig en snel werken zolang er geen complexe logica is.

Nadelen:

Encapsulatie is geschonden, het is gemakkelijk om een onjuiste toestand van het object te krijgen, wat leidt tot verwarring.

Positief geval

Het gebruik van property en het verbergen van het interne attribuut via _celsius. Validatie, caching en logica worden gecentraliseerd binnen property.