El polimorfismo cerró con una advertencia: nada impide escribir odisea.precio = -5 o fausto.stock = -3, y a partir de ahí todos los cálculos de Papyrus mienten. En 05-01 escribiste vender() precisamente para que el stock nunca quedara negativo... pero cualquiera puede saltarse el método y tocar el atributo directamente. La encapsulación es el principio que corrige esto: cada objeto protege sus datos internos y solo permite modificarlos por vías controladas, de modo que sus invariantes — las reglas que siempre deben cumplirse, como "el stock nunca es negativo" — no puedan romperse ni por accidente. Python lo resuelve a su manera: sin candados de verdad, con convenciones claras y una herramienta elegante llamada property.

1. Qué es encapsular y por qué importa
2. La convención del guion bajo: _protegido
3. Doble guion bajo y name mangling: __privado
4. El problema de los getters/setters al estilo Java
5. @property: atributos calculados y validados
6. El setter: validar sin cambiar la interfaz
7. Producto blindado: la versión final
8. Errores comunes y consejos
9. Ejercicios con soluciones

Encapsular es separar el qué (la interfaz pública: precio_final(), vender()) del cómo (los detalles internos: en qué atributo se guarda el stock, cómo se valida). Los beneficios son concretos:

• Invariantes del negocio garantizadas: en Papyrus, el stock nunca es negativo, el precio nunca es negativo, un código de socio siempre tiene el formato NOMBRE-NNN. Si el objeto vigila sus propios datos, ninguna parte del programa puede corromperlos.
• Libertad para cambiar por dentro: si mañana el stock pasa de un entero a un desglose por almacén, el resto del código no se entera mientras hay_stock() siga respondiendo igual.
• Menos superficie de error: quien usa la clase solo ve lo que debe usar.

Ahora bien, una diferencia cultural importante: Python no tiene atributos privados de verdad (como private en Java o C#). Su filosofía se resume en la frase "somos todos adultos que consienten": el lenguaje señala qué es interno, y confía en que lo respetes.

Un guion bajo inicial marca un atributo o método como interno: "no lo toques desde fuera; puede cambiar sin previo aviso". Es solo una convención — Python no lo impide — pero toda la comunidad la respeta.

La última línea funciona, y ahí está la clave: _compras es una señal de tráfico, no un muro. Los buenos linters y revisores de código la marcarán, y ese contrato social es sorprendentemente eficaz.

Dos guiones bajos iniciales (sin dos finales) activan el name mangling (retorcimiento de nombres): Python renombra el atributo internamente a _NombreClase__atributo.

Puntos que debes tener claros:

• No es seguridad real: cualquiera que conozca el truco accede con _Socio__codigo. Es ocultación superficial, no cifrado ni protección.
• Su propósito genuino es evitar colisiones de nombres en herencia: si Producto usa __contador y una subclase define otro __contador, el mangling los mantiene separados (_Producto__contador vs _Libro__contador).
• En el día a día, la comunidad Python prefiere el guion bajo simple. Reserva __privado para cuando escribas clases pensadas para ser heredadas por desconocidos.

En lenguajes con privacidad estricta, la receta clásica es: atributo privado + método get + método set. Trasladada literalmente a Python queda así:

Valida, sí, pero al precio de una interfaz fea y de romper todo el código existente que hacía libro.precio. Python tiene algo mejor.

Una property es un método disfrazado de atributo: se lee como libro.precio (sin paréntesis), pero por debajo ejecuta código. Es un decorador de la biblioteca estándar (los decoradores en general se estudian en el módulo 8; aquí basta con saber usarlo).

Sin setter, la property crea un atributo de solo lectura: ya nadie puede asignar un precio por las bravas. Las properties también sirven para atributos calculados que no se almacenan:

Para permitir la asignación con control, se añade el setter con @nombre.setter:

Ahora la validación es automática y la sintaxis sigue siendo natural:

raise ValueError(...) detiene el programa con un mensaje claro; ya lo usaste conceptualmente al validar entradas, y el módulo 7 enseñará a capturar estos errores con try/except. Lo importante hoy: el objeto rechaza el dato inválido en el momento exacto en que intenta entrar.

La última fila de "¿rompe el código?" esconde la gran ventaja estratégica: puedes empezar con un atributo público normal (self.precio) y convertirlo en property años después, cuando haga falta validar, sin tocar ni una línea del código cliente. Por eso en Python no se escriben getters/setters preventivos "por si acaso", como exige la ortodoxia Java.

Aplicamos todo a la clase base de la jerarquía (05-02). Invariantes a proteger: precio ≥ 0, stock entero ≥ 0.

Dos sutilezas de oro en este código:

• __init__ asigna a self.precio, no a self._precio: así la validación se aplica también al construir. Producto("Fantasma", -3, 1) falla inmediatamente, que es donde debe fallar.
• Las subclases heredan el blindaje gratis: Libro, Revista y LibroDigital no cambian ni una línea y sus precios y stocks quedan protegidos, porque sus super().__init__(...) desembocan en estos setters.

• Recursión infinita en la property: escribir return self.precio dentro del getter de precio (o self.precio = valor en su setter) llama a la property una y otra vez hasta RecursionError. Dentro del getter/setter, usa siempre el atributo interno self._precio.
• Validar en el setter pero asignar self._precio en __init__: el objeto nace sin validar. Asigna en __init__ al nombre público (self.precio = precio) para que el setter actúe desde el primer segundo.
• Creer que __privado protege datos sensibles: el name mangling se salta con obj._Clase__atributo; no es un mecanismo de seguridad, solo de higiene de nombres en herencia.
• Escribir getters/setters get_x()/set_x() preventivos para todo: es ruido heredado de Java. Atributo público primero; property cuando (y solo cuando) necesites validar o calcular.
• Olvidar el @property encima del getter y dejar solo @precio.setter: NameError, porque el setter se define a partir de la property existente. El orden es: primero @property, después @nombre.setter.
• Consejo: decide qué es interfaz pública (lo que documentas: titulo, precio, stock, vender(), precio_final()) y marca el resto con _. Una clase con pocas puertas de entrada es una clase fácil de razonar y de mantener.

En Papyrus, el título de un producto no debe cambiar una vez creado (es su identidad en el catálogo). Convierte titulo en una property sin setter que además valide en __init__ (a través de un método interno o del propio guardado) que no sea una cadena vacía tras strip(). Comprueba que odisea.titulo = "Otro" falla y que Producto(" ", 5.0) lanza ValueError.

Crea la clase Socio con nombre público y una property codigo con getter y setter. El setter debe validar el formato NOMBRE-NNN de Papyrus: la parte izquierda alfabética y en mayúsculas, un guion, y tres dígitos (repasa split(), isalpha(), isdigit(), isupper() de 04-05). "LUIS-001" y "MARTA-002" deben pasar; "luis-001", "LUIS001" y "LUIS-1" deben lanzar ValueError.

Añade a Producto un atributo interno _reservas (lista) y los métodos reservar(cliente) y atender_reserva(). reservar solo se permite si NO hay stock (si hay, que devuelva el aviso "Hay stock: compra directa"); atender_reserva saca al primer cliente de la lista (orden de llegada) o devuelve None si no hay reservas. Simula: Fausto con stock 0, reservan Júlia y Omar, llega stock, se atiende a Júlia.

Solución 1:

Sin setter, la property es de solo lectura: la identidad del producto queda sellada al nacer.

Solución 2:

Es la misma regla que es_socio_valido() de papyrus_utils.py, pero ahora vive donde debe: en el objeto que guarda el dato, imposible de olvidar.

Solución 3:

La lista _reservas nunca se manipula desde fuera: el orden de llegada está garantizado por construcción. (Para colas largas, recuerda que deque de 04-06 hace popleft() en tiempo constante; aquí pop(0) basta.)

La encapsulación ha cerrado la grieta que el polimorfismo dejó a la vista: _interno señala lo que no debe tocarse, __privado añade name mangling (higiene de nombres, nunca seguridad real), y @property con su @setter consigue lo mejor de dos mundos — la sintaxis natural de un atributo con la validación de un método. La clase Producto de Papyrus ya no admite precios negativos ni stocks imposibles, y todas sus subclases heredan el blindaje sin cambiar una línea. Con datos unidos a su comportamiento (05-01), organizados en jerarquía (05-02), polimórficos (05-03) y protegidos (05-04), solo falta que tus objetos hablen el idioma nativo de Python: que print(odisea) muestre algo digno, que sorted(catalogo) ordene libros sin key=, que libro in carrito simplemente funcione. Todo eso lo conceden los métodos mágicos, y con ellos saldaremos por fin el gancho pendiente desde 05-01: el print "feo". Es la próxima lección.