Hace poco volví a revisar la lógica de registro y suspiré.
Solo había pulsado un botón, pero el controlador de vista llamaba directamente a seis o siete objetos para validar datos, hacer una solicitud de red, guardar el token, registrar notificaciones y más.
Tenía que reutilizarlo en otra pantalla, pero no quería copiar toda la secuencia y combinación de llamadas.
Ahí es donde entra el patrón Facade de Swift.
En resumen, el patrón Facade envuelve un subsistema complejo con varios objetos tras un único método, como signUp(). El código cliente no necesita saber cómo funciona por dentro.
Los límites entre convertir interfaces, controlar el acceso y añadir funcionalidad se ven claramente en Comparación entre Adapter, Facade, Proxy y Decorator.
Hoy explicaré cómo aplicar este patrón con código Swift y, basándome en mi experiencia, cuándo conviene usarlo y cuándo puede ser contraproducente.
¿Qué es el patrón Facade?
Facade originalmente significa «fachada», la parte frontal de un edificio.
Desde fuera solo ves una fachada limpia, pero dentro hay tuberías, cableado y todo tipo de instalaciones complejas.
En el software ocurre lo mismo.
Cuando un subsistema contiene varias clases que se llaman entre sí, colocas un único punto de contacto delante.
El código cliente solo tiene que comunicarse con ese punto.
La idea clave es un «punto de entrada simplificado».
Facade no elimina la complejidad: la encierra en un solo lugar y deja abierta hacia fuera una única puerta sencilla.
Lo importante es que oculta la implementación interna, no que la elimine.
Las tuberías siguen ahí; simplemente están ocultas detrás de la pared.
Así se implementa directamente en Swift
Con palabras cuesta hacerse una idea, así que veamos el código.
Supongamos que el flujo de registro tiene tres subsistemas: validación, registro en el servidor y almacenamiento del token.
Primero, los objetos internos que queremos ocultar.
struct Validator { func check(_ email: String) -> Bool { email.contains("@") } }
struct AuthAPI { func register(_ email: String) -> String { "token_\(email)" } }
struct TokenStore { func save(_ token: String) { /* Almacenamiento en Keychain */ } }Si el controlador de vista llama directamente a los tres, el código se vuelve desordenado.
Por eso Facade los coordina en su lugar.
struct SignUpFacade {
private let validator = Validator()
private let api = AuthAPI()
private let store = TokenStore()
func signUp(email: String) -> Bool {
guard validator.check(email) else { return false }
let token = api.register(email) // Gestionar aquí el orden interno
store.save(token)
return true
}
}Ahora el código cliente solo necesita una línea.
Así: SignUpFacade().signUp(email: "[email protected]").
El código cliente no necesita conocer el orden de validar primero y guardar después el token.
Aunque después cambie el orden o se añada un paso, solo hay que modificar el interior de Facade.
¿Cuándo conviene usarlo y cuándo evitarlo?
He resumido los criterios que obtuve después de usarlo personalmente.
Cuándo encaja Facade
- Cuando el código repite en varios lugares llamadas a varios objetos en el mismo orden fijo
- Cuando quieres envolver una biblioteca externa o un SDK complejo y darle nombres sencillos adaptados a tu aplicación
- Cuando el controlador de vista sabe demasiado y quieres aligerarlo
Cuándo es mejor evitarlo
- Cuando el subsistema ya es sencillo y hay poco que ocultar (solo añades una capa innecesaria)
- Cuando necesitas control detallado cada vez y acabas saltándote Facade para llamar directamente a los objetos internos
Hay un punto que quiero destacar.
Facade no «bloquea» el acceso interno.
Solo ofrece un camino sencillo; si hace falta, también puedes usar directamente los objetos internos.
Por eso su naturaleza es distinta de la de otros patrones que pretenden controlar todo acceso.
Algunas preguntas frecuentes
P. ¿En qué se diferencia Facade de una simple función de utilidad?
Una función de utilidad suele contener una única función independiente, mientras que Facade coordina la colaboración y el orden de varios objetos.
La diferencia está en «qué se oculta».
P. ¿Tiene que ser un protocolo?
No es obligatorio.
Pero si quieres sustituir Facade por un objeto falso en las pruebas, abstraerlo mediante un protocolo resulta mucho más cómodo.
P. Lo confundo con el patrón Adapter.
Adapter busca adaptar interfaces incompatibles, mientras que Facade busca presentar lo complejo de forma sencilla.
Es fácil recordarlo si tienes presente que sus objetivos son distintos.
Resumen
Cada vez que veas un bloque complejo de llamadas, pregúntate: «¿Puedo envolverlo en un solo método?»
Solo esa pregunta suele hacer que el código sea mucho más fácil de leer.
Facade no es un patrón llamativo, pero sí una herramienta fiable a la que se recurre con frecuencia en proyectos reales.
Te animo a probarlo de forma sencilla empezando por el ejemplo de registro de hoy.
