Antwoord.

De @property decorator maakt het mogelijk om een methode om te zetten in een "virtueel" attribuut van de klasse: voor de gebruiker van de klasse lijkt het een normale eigenschap, maar het wordt beheerd door de logica van een Python-functie. Oorspronkelijk waren in Python alle instantie-attributen rechtstreeks toegankelijk, maar voor het ondersteunen van encapsulatie was een mechanisme voor toegangsbeheer van gegevens nodig zonder de interface van de klasse te veranderen.

Geschiedenis:

In eerdere versies van Python was er geen expliciet mechanisme voor het beperken van de toegang tot attributen. De taak van encapsulatie werd opgelost door middel van overeenkomsten (bijvoorbeeld het gebruik van een underscore), maar eventuele wijzigingen aan de logica voor opslag/validatie van waarden konden de compatibiliteit verstoren. Met de komst van de @property decorator werd het mogelijk om een methode als attribuut te declareren, het te voorzien van een getter, setter en deleter, terwijl de oude interface van de klasse behouden bleef.

Probleem:

Wanneer het later nodig is om logica voor validatie of berekening van de waarde van een veld toe te voegen, is het te duur om de hele interface opnieuw te construeren — je moet alle toegangspunten naar de variabele aanpassen. Bovendien mag de interne implementatie van het veld niet blootgelegd worden aan externe consumenten van de klasse. @property maakt het eenvoudig om toegang te "virtualiseren".

Oplossing:

@property implementeert het patroon "getter/setter met interfacebescherming": het is mogelijk om een berekenbaar attribuut toe te voegen of de instelling van de waarde te controleren zonder de clientcode te veranderen.

Voorbeeld code:

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 is lager dan het absolute nulpunt!")
        self._celsius = value

    @property
    def fahrenheit(self):
        return self._celsius * 9 / 5 + 32

# Gebruik
obj = Temperature(25)
print(obj.celsius)   # 25
print(obj.fahrenheit) # 77.0
obj.celsius = -300   # ValueError

Belangrijke kenmerken:

Maakt het mogelijk om berekenbare, gevalideerde of gecachete eigenschappen te implementeren zonder de clientinterface te veranderen
Biedt de eigenschapsinterface (zonder haakjes bij toegang)
Maakt het mogelijk om zowel lezen, schrijven als verwijderen van waarden te controleren

Vragen met een strikvraag.

Kan je altijd een property toevoegen aan elk veld van de klasse zonder retrocompatibiliteit te schenden?

Nee. Als het attribuut openbaar was en als een normale variabele werd gebruikt, is vervanging door een property mogelijk zonder problemen. Maar als er ergens toegang was via __dict__ of typecontroles waren uitgevoerd via type(obj.attr), kan dit onverwacht gedrag opleveren.

Kan je alleen een setter declareren zonder een getter voor een eigenschap?

Nee, eerst is een getter verplicht (methode met @property), anders weet Python niet aan welke eigenschap de setter moet worden „verbonden".

Wat is de volgorde van de decorators @property/@setter/@deleter en waarom?

Altijd eerst schrijf je @property (dit creëert het eigenschap object), daarna via de naam van de methode — @<naam>.setter en @<naam>.deleter (ze vullen de eerder gemaakte property aan).

class A:
    @property
    def value(self):
        ...
    @value.setter
    def value(self, v):
        ...

Typische fouten en anti-patronen

Directe toegang tot een besloten attribuut (bijvoorbeeld, self._celsius) buiten de klasse
Schending van het principe van encapsulatie: overbodige logica in getter/setter
Overschrijven van property in afgeleiden klassen met naamconflicten

Voorbeeld uit het leven

Negatieve case

De velden van de klasse waren openbaar, vervolgens werd er een berekenbaar attribuut via property toegevoegd na de release van de publieke API. In de oude code verandert toegang tot het attribuut impliciet het gedrag of genereert een fout.

Voordelen:

De gebruiker hoeft geen toegang tot het attribuut te veranderen

Nadelen:

Er ontstaan onverwachte storingen in de code als toegang voorwaardelijk wordt op basis van de logica van de setter/getter
Lagere compatibiliteit als de client directe toegang tot dict gebruikte

Positieve case

Zodra bij het ontwerp de velden als besloten (met één underscore) zijn vastgesteld en gebruikers alleen via methoden/properties werkten. Het toevoegen van nieuwe logica in de property in de toekomst ging zonder wijzigingen in de clientinterface.