2. Acoplamiento: definición, tipos y su influencia en la arquitectura

El acoplamiento describe cuán estrechamente dependen entre sí los componentes de un sistema. Comprenderlo permite razonar sobre la independencia de los módulos, anticipar el costo de los cambios y construir arquitecturas que se mantengan limpias a lo largo del tiempo.

2.1 ¿Qué es el acoplamiento?

El acoplamiento representa el grado de conocimiento que un módulo necesita acerca de otro para funcionar. Puede manifestarse como llamadas directas, acceso a estructuras de datos internas, contratos compartidos o dependencias implícitas como formatos de archivos. Cuanto más información necesita un componente sobre otro, mayor es el acoplamiento y menor la libertad para evolucionarlos por separado.

2.2 Clasificación: débil, moderado y fuerte

Evaluar la fuerza del acoplamiento ayuda a decidir si debemos refactorizar o si el diseño es sustentable. Una escala sencilla agrupa los escenarios más frecuentes:

1. Débil: los módulos interactúan a través de interfaces o mensajes bien definidos. Alterar la implementación de un componente no impone cambios en sus consumidores. Es el ideal en sistemas modulares.
2. Moderado: existe una dependencia explícita, aunque estable. Suele aparecer cuando se comparten modelos de datos o cuando un servicio expone estructuras específicas. Ofrece flexibilidad razonable siempre que el contrato se gestione cuidadosamente.
3. Fuerte: los componentes se conocen en detalle, acceden a datos internos o dependen de secuencias concretas de llamadas. Una modificación requiere actualizar numerosos puntos del sistema, volviendo las iteraciones lentas y arriesgadas.

2.3 Influencia en la arquitectura y la independencia de módulos

La arquitectura define cómo se organizan los módulos y la direccionalidad de sus dependencias. Un acoplamiento débil posibilita estrategias como capas independientes, microservicios o módulos de dominio claramente delimitados. En cambio, el acoplamiento fuerte genera arquitecturas monolíticas donde cualquier cambio se propaga sin control. Diseñar con dependencias controladas permite que los equipos evolucionen partes del sistema de forma paralela, facilita desplegar funcionalidades por etapas y reduce el impacto de fallas localizando mejor los problemas.

2.4 Indicadores prácticos y métricas

Algunos indicadores que revelan acoplamiento excesivo son la necesidad de modificar varias capas para un cambio simple, el uso de variables globales o la cantidad de clases importadas en cada archivo. Métricas como fan-in y fan-out, o la complejidad ciclomática acumulada por dependencia, ayudan a cuantificar el riesgo. Estas mediciones funcionan como alarma temprana: cuando los valores crecen, conviene evaluar la separación en componentes, introducir eventos o abstraer contratos.

2.5 Ejemplo en Java

En el siguiente escenario se observa un acoplamiento fuerte: un servicio conoce la base de datos, el formato de los reportes y la forma de enviar notificaciones. Cualquier cambio en esas capas obliga a editar la clase central.

class ReporteFinancieroService {
    private final Connection connection;

    ReporteFinancieroService(Connection connection) {
        this.connection = connection;
    }

    void generarYEnviar(int trimestre) throws SQLException {
        PreparedStatement ps = connection.prepareStatement(
            "SELECT * FROM reportes WHERE trimestre = ?");
        ps.setInt(1, trimestre);
        ResultSet rs = ps.executeQuery();
        Reporte reporte = construirReporte(rs);
        EmailClient.enviar("finanzas@empresa.com", reporte.renderizar());
    }

    private Reporte construirReporte(ResultSet rs) {
        // Procesa el ResultSet de forma directa
    }
}

Al introducir contratos específicos se reduce el acoplamiento: cada colaborador ofrece un servicio bien definido y el código principal se concentra en orquestar la lógica. Este diseño facilita pruebas unitarias en Java y permite intercambiar implementaciones sin romper dependencias internas.

interface RepositorioReportes {
    Reporte buscarPorTrimestre(int trimestre);
}

interface GeneradorEntrega {
    void enviar(Reporte reporte);
}

class ReporteFinancieroService {
    private final RepositorioReportes repositorio;
    private final GeneradorEntrega entrega;

    ReporteFinancieroService(RepositorioReportes repositorio, GeneradorEntrega entrega) {
        this.repositorio = repositorio;
        this.entrega = entrega;
    }

    void generarYEnviar(int trimestre) {
        Reporte reporte = repositorio.buscarPorTrimestre(trimestre);
        validar(reporte);
        entrega.enviar(reporte);
    }

    private void validar(Reporte reporte) {
        // Reglas de negocio acotadas al servicio
    }
}

Gracias a estas dependencias débiles, el repositorio puede almacenar en archivos o servicios remotos, y el componente de entrega puede elegir entre correo electrónico, mensajería o dashboards. La arquitectura gana flexibilidad sin sacrificar claridad.