El patrón Separated Interface consiste en definir una interfaz en un paquete (o módulo) y colocar su implementación en otro paquete distinto. Esto permite que el cliente de la interfaz dependa únicamente de la definición y no de la implementación concreta.
Es una técnica fundamental para aplicar el Principio de Inversión de Dependencias (DIP) y lograr un sistema altamente modular y fácil de probar.
# ¿Cuándo usarlo?
Es esencial cuando deseas desacoplar componentes que interactúan entre sí, permitiendo cambiar la implementación sin afectar al código que utiliza la interfaz. Es especialmente útil para servicios externos, acceso a datos o cualquier componente cuya implementación pueda variar.
# Ventajas
-
verified
Bajo acoplamiento
Los clientes solo conocen la interfaz, no la implementación.
-
verified
Sustituibilidad
Facilita el cambio de una implementación por otra (por ejemplo, para pruebas o diferentes proveedores).
-
verified
Estructura limpia
Promueve una clara separación de responsabilidades entre paquetes.
# Desventajas
-
warning
Complejidad adicional
Requiere gestionar más archivos y estructuras de paquetes.
-
warning
Indirección
Puede hacer que el seguimiento del flujo de ejecución sea un poco más complejo inicialmente.
# Ejemplo Detallado en Java
Supongamos una interfaz de correo electrónico definida en el dominio, con implementaciones reales y de prueba en paquetes aparte:
dominio/ServicioEmail.java
public interface ServicioEmail {
void enviar(String para, String mensaje);
}infraestructura/ServicioEmailSMTP.java
public class ServicioEmailSMTP implements ServicioEmail {
@Override
public void enviar(String para, String mensaje) {
// Implementación real usando protocolos de correo
}
}# Conclusiones
El patrón Separated Interface es un pilar de la arquitectura limpia. Al separar qué se hace de cómo se hace, creamos sistemas que son resilientes al cambio, fáciles de probar y con una estructura modular clara y profesional.