Facundo Uferer
1. El Constructor: La Aduana de los Invariantes
Un invariante es una regla de negocio que NUNCA debe violarse (ej. una nota entre 0 y 10, un saldo no negativo). El constructor es el guardián fronterizo: si los datos son inválidos, los reemplaza por un valor por defecto seguro y avisa por consola. El objeto siempre nace en el Heap, pero nunca con datos rotos.
La nota cumple el invariante (0 a 10). El objeto nace con garantía absoluta de integridad.
2. Sobrecarga y Delegación de Constructores con this()
Tener múltiples constructores no significa duplicar las validaciones. Con this(...), los constructores secundarios delegan en cascada hacia el constructor canónico principal. Regla estricta de Java: this() debe ser la primera sentencia.
Las validaciones residen en UN solo lugar. Si cambian las reglas de precio, no tenés que retocar 3 constructores.
3. La Matriz de los 4 Modificadores de Acceso
Java ofrece 4 niveles concéntricos de visibilidad. La regla de oro del encapsulamiento es el Principio del Menor Privilegio: empezá siempre con private y abrí visibilidad solo si hay una razón de diseño estricta.
Ideal para los atributos de estado. Ninguna clase externa puede leer o escribir directamente.
4. La Fuga de Referencia (Reference Leak)
Marcar un atributo como private NO garantiza encapsulamiento si el getter devuelve la referencia directa a un objeto mutable (como un array o Date). El código cliente puede corromper tu array interno sin tocar ningún setter.
Al devolver la referencia original, el encapsulamiento se destruyó. El cliente corrompió la historia clínica.
5. Inmutabilidad: El Encapsulamiento Perfecto
Una clase inmutable (como String, LocalDate o un record de Java 16+) no expone setters y declara sus campos private final. Es inmune a condiciones de carrera en entornos multihilo porque su estado jamás muta tras salir del constructor.
Al diseñar con inmutabilidad, eliminás de raíz clases enteras de bugs: carreras de datos, aliasing accidental y corrupción de estado.