property: getter, setter e validação

O problema do atributo livre

Imagine uma classe Produto com um atributo preco. Se ele for um campo público comum, nada impede alguém de escrever produto.preco = -50, e agora o seu sistema tem um produto de preço negativo. Em muitas linguagens, a saída seria esconder o campo e obrigar todo mundo a usar métodos getPreco e setPreco, com a validação dentro do set. Funciona, mas é verboso: quem usa a classe precisa chamar métodos toda vez, e o código fica cheio de parênteses. O Python resolve isso de um jeito mais elegante, sem sacrificar a simplicidade de escrever produto.preco.

A ideia da property é começar simples e só adicionar controle quando precisar, sem quebrar quem já usa a classe. Você pode lançar uma classe com um atributo público comum e, no dia em que surgir a necessidade de validar, transformá-lo em property sem mudar uma linha do código que a consome. A interface externa continua idêntica, produto.preco para ler e produto.preco = 10 para escrever, mas agora há funções suas rodando por trás. Esse é o encapsulamento à moda do Python: cobre a lógica quando ela é necessária, sem cerimônia antecipada.

O getter com @property

O primeiro passo é o getter. Você escreve um método com o nome do atributo e o decora com @property. A partir daí, ao ler obj.preco, o Python chama esse método em vez de devolver um campo. Por convenção, o valor real fica guardado em um atributo com um sublinhado na frente, como _preco, sinalizando que é interno. Repare que quem usa a classe nem percebe: escreve produto.preco, sem parênteses, exatamente como faria com um campo comum. A property também é ótima para valores calculados, que derivam de outros atributos e não precisam ser guardados.

class Circulo:
    def __init__(self, raio):
        self._raio = raio

    @property
    def raio(self):
        return self._raio

    @property
    def area(self):          # valor calculado, sem campo proprio
        return 3.14159 * self._raio ** 2

c = Circulo(2)
print(c.raio)   # 2  (chamou o getter, sem parenteses)
print(c.area)   # 12.56636  (calculado na hora)

@property faz raio e area serem lidos como atributos; area é calculada a cada acesso.

O setter que valida

O poder de verdade aparece no setter. Depois de definir o getter com @property, você cria um segundo método com o mesmo nome do atributo, decorado com @nome.setter, e é ali que a validação mora. Toda vez que alguém escrever produto.preco = valor, o Python chamará esse método, passando o valor. Se ele for inválido, você levanta uma exceção e a atribuição errada nunca acontece. O resultado é uma classe que se defende: é impossível colocá-la em um estado inconsistente pela porta da frente, e mesmo assim a sintaxe de uso permanece a de um campo comum.

class Produto:
    def __init__(self, preco):
        self.preco = preco       # ja passa pelo setter e valida

    @property
    def preco(self):
        return self._preco

    @preco.setter
    def preco(self, valor):
        if not isinstance(valor, (int, float)):
            raise TypeError("preco deve ser numero")
        if valor < 0:
            raise ValueError("preco nao pode ser negativo")
        self._preco = valor

p = Produto(10)
p.preco = 25        # ok, passa na validacao
print(p.preco)      # 25
# p.preco = -5      # ValueError: preco nao pode ser negativo

O setter valida a cada atribuição; até o __init__ usa self.preco para passar pela validação.

Um detalhe elegante do exemplo: o __init__ atribui self.preco = preco, e não self._preco = preco. Com isso, até a criação do objeto passa pela validação do setter, então nem no construtor um valor inválido escapa. Essa é a marca de uma classe bem projetada no avançado: ela garante suas próprias invariantes, aquelas regras que precisam ser sempre verdadeiras, como preço não negativo. A property centraliza essa garantia em um único lugar, em vez de espalhar validações por todo o código que mexe no objeto.