Diseño por Contrato (Design by Contract) e Invariantes

Creado por Bertrand Meyer, el Diseño por Contrato (Design by Contract - DbC) es un enfoque formal para diseñar software donde los componentes colaboran mediante contratos explícitos, precisos e inquebrantables.

Al igual que en un contrato legal entre dos partes, el método establece qué exige para ejecutarse (Precondiciones) y qué promete entregar al finalizar (Postcondiciones), mientras que la entidad garantiza que su estado interno siempre será coherente (Invariantes).

1. Los Tres Elementos del Contrato #

1CLIENTE (Llamador)
2                      │
3                      │ 1. Cumple las PRECONDICIONES (Parámetros válidos, estado previo)
4                      ▼
5         ┌─────────────────────────┐
6         │     MÉTODO / SERVICIO   │ ◄─── Debe mantener la INVARIANTE de la entidad
7         └────────────┬────────────┘
8                      │
9                      │ 2. Garantiza las POSTCONDICIONES (Resultado correcto, efectos garantizados)
10                      ▼
11               CLIENTE (Llamador)

1. Precondición (Requires): Requisitos obligatorios que el cliente debe satisfacer antes de llamar al método. Si falla una precondición, el error es del código cliente que llamó.
2. Postcondición (Ensures): Garantías que el método asegura que serán ciertas al terminar. Si falla una postcondición, el error es de la implementación interna del método.
3. Invariante de Clase (Class Invariant): Una regla de negocio que debe cumplirse siempre durante todo el ciclo de vida del objeto (después del constructor y antes/después de cualquier método público).

2. Validación en Fronteras vs Confianza en el Dominio #

Un error común en código sucio es la programación defensiva paranoica: llenar cada método privado de comprobaciones repetitivas if (x == null || x < 0).

• En los Límites del Sistema (Fronteras): Valida rigurosamente la entrada de usuarios, peticiones HTTP y datos externos.
• En el Núcleo de Dominio: Encapsula los datos en Objetos de Valor (Value Objects) que validan sus invariantes en el constructor. Una vez creado el objeto, los demás métodos confían en el contrato y no necesitan comprobaciones redundantes.

3. Ejemplo Práctico: Entidad con Invariantes y Contratos #