@property y encapsulación

Teoría22 min20 XP

Un objeto bien diseñado PROTEGE sus datos: no deja que cualquiera ponga un saldo negativo o un valor inválido. Eso es la ENCAPSULACIÓN. Y a veces quieres exponer un valor que se CALCULA (el total con IVA, que depende del valor) como si fuera un atributo normal, sin paréntesis. Para ambas cosas, Python tiene una herramienta elegante: @property. Hoy aprendes a proteger y a calcular con propiedades —el toque profesional en el diseño de clases—.

La cocina y el menú

La convención de lo "privado"

El guion bajo _ como señal

Python no tiene atributos estrictamente privados como otros lenguajes, pero usa una CONVENCIÓN clara:

_atributo (un guion bajo): señal de "esto es interno, no lo toques desde afuera". Python no lo impide, pero es un acuerdo entre programadores: los atributos con _ son detalles internos que podrían cambiar. Respétalos.
__atributo (dos guiones bajos): activa el "name mangling" —Python le cambia el nombre para dificultar el acceso accidental desde fuera o desde subclases—. Se usa menos; el guion simple basta casi siempre.

La idea de fondo: un objeto expone una interfaz PÚBLICA (métodos y properties bien pensados) y esconde sus detalles INTERNOS (atributos con _). Quien usa tu objeto interactúa con la interfaz, no con las tripas. Así puedes cambiar el interior sin romper a quien lo usa —y proteger las reglas del objeto—.

@property: atributos calculados y validados

@property convierte un método en un atributo de solo lectura: g.valor (sin paréntesis) llama al método valor() pero se usa como si fuera un dato. Con @valor.setter agregas la lógica de asignación: g.valor = 5000 pasa por el setter, que puede VALIDAR (aquí rechaza negativos). Y con_iva es una propiedad CALCULADA: no se guarda, se deriva de _valor cada vez que la pides —siempre coherente, imposible de desincronizar—. Es lo mismo que "lo derivado se calcula, no se guarda" que viste en React (SC-06), aplicado a objetos.

Por qué properties y no atributos normales

¿Por qué no dejar valor como atributo público normal? Porque con @property:

Validas al asignar: un atributo normal aceptaría g.valor = -100 sin queja; el setter lo rechaza. El objeto protege sus propias reglas.
Calculas al vuelo: con_iva no ocupa memoria ni se puede desincronizar —se calcula de _valor cada vez—. Si guardaras con_iva como atributo, tendrías que recalcularlo a mano cada vez que cambia valor.
Cambias el interior sin romper afuera: quien usa g.valor no sabe (ni le importa) si es un atributo guardado o un cálculo. Puedes cambiar la implementación sin tocar el código que lo usa.

La belleza es que la interfaz se mantiene simple (g.valor, g.con_iva, como atributos) mientras por dentro hay validación y cálculo. Empieza con atributos normales y cambia a @property cuando necesites validar o calcular —sin romper el código que ya los usa—.

¿Qué permite @property y qué ventaja tiene sobre un atributo normal?

Mini-reto

Protege una Cuenta de Mi Bolsillo: 1) guarda el saldo como _saldo (interno) e inicialízalo en __init__; 2) expón saldo con @property (getter) y un setter que RECHACE valores negativos con ValueError; 3) agrega una propiedad calculada saldo_con_bono que devuelva el saldo × 1.05; 4) crea una cuenta, lee saldo y saldo_con_bono, asigna un saldo válido, e intenta uno negativo para ver la validación. Nota que saldo_con_bono se recalcula solo.

Qué sigue

Ya proteges y calculas con properties. La última lección del módulo trae dos joyas modernas: las DATACLASSES (que generan __init__, __repr__ y __eq__ por ti, eliminando código repetitivo) y los PROTOCOLS (el "duck typing" tipado, primo del tipado estructural de TypeScript). El toque final para escribir POO pythónica y elegante.