Cuando una aplicación crece y maneja múltiples subsistemas como seguridad, analíticas y transferencias, la complejidad se vuelve difícil de controlar. El patrón de diseño Facade resuelve exactamente este problema al crear una clase que encapsula toda esa complejidad y expone una interfaz sencilla para el resto del código. Si alguna vez agrupaste varias llamadas a distintos servicios dentro de una sola clase, ya lo estabas aplicando sin saberlo.
¿Qué es el patrón Facade y por qué lo usan apps como Facebook o YouTube?
El Facade es un patrón estructural que actúa como punto de entrada único hacia varios subsistemas complejos [0:06]. En lugar de que la vista o el presentador conozcan y coordinen cada subsistema por separado, la fachada se encarga de orquestar todo internamente.
Aplicaciones de gran escala como Facebook, YouTube e Instagram lo utilizan porque manejan subsistemas de login, seguridad y analytics de forma simultánea [0:24]. En el proyecto Plaxi Wallet se replican estos mismos conceptos con cuatro subsistemas: analíticas, login, seguridad y transferencias.
La ventaja principal es que para la capa de vista la operación es totalmente transparente: solo invoca un método y la fachada coordina todo por debajo [0:44].
¿Cómo se combinan los patrones Proxy y Facade en código?
Un punto clave es que los patrones de diseño se pueden combinar sin importar su categoría [1:06]. En este caso, el Transfer Proxy y el Transfer Facade trabajan juntos. El proxy controla el acceso y la fachada simplifica la orquestación.
Dentro del paquete de UI se crea la clase TransferFacade, que encapsula tres subsistemas:
AnalyticsManager: registra cada transferencia para saber cuántas lleva el usuario en un periodo determinado [1:42].
SecurityManager: genera un token necesario para validar que la transferencia sea segura [1:30].
TransferManager: ejecuta la transacción real utilizando el token obtenido [3:18].
kotlin
class AnalyticsManager {
fun registerTransfer(token: String) {
// Registró la transferencia
}
}
class SecurityManager {
fun getToken(): String {
return "token_de_transferencia"
}
}
class TransferManager {
fun transfer(token: String) {
// Aquí se hace la transferencia
}
}
La clase TransferFacade instancia cada manager y expone un único método transfer que coordina todo el flujo [2:50]:
kotlin
class TransferFacade {
val analyticsManager = AnalyticsManager()
val securityManager = SecurityManager()
val transferManager = TransferManager()
fun transfer(){ val token = securityManager.getToken() analyticsManager.registerTransfer(token) transferManager.transfer(token)}
}
Con este diseño, el token se obtiene una sola vez y se reutiliza tanto para registrar la analítica como para ejecutar la transferencia [3:40].
¿Qué beneficios aporta la responsabilidad única en la fachada?
Si en el futuro se necesita agregar o eliminar un subsistema, la única clase que cambia es TransferFacade [3:56]. Esto aplica el principio de responsabilidad única: cada manager se enfoca en su tarea y la fachada se enfoca en coordinar.
¿Cómo fluye la comunicación desde la vista?
El flujo queda limpio y lineal: la vista llama al presentador, el presentador llama a la fachada y ella se encarga de conectar con todos los subsistemas [4:08]. La vista nunca necesita conocer la existencia de SecurityManager ni de AnalyticsManager.
¿Cuáles son los patrones estructurales más usados en Android?
Los tres patrones estructurales que más se aplican en desarrollo Android son Facade, Proxy y Adapter [4:22]. Cada uno resuelve un problema distinto:
Facade: simplifica la interacción con múltiples subsistemas.
Proxy: controla y filtra el acceso a un objeto.
Adapter: hace compatibles interfaces que originalmente no lo son.
Estos patrones aportan mantenibilidad y escalabilidad al proyecto. Además, al tener clases con responsabilidad única, cada componente se puede testear de forma independiente [4:30], lo que mejora la calidad del código a largo plazo.
¿Ya estás usando alguno de estos patrones en tus proyectos? Comparte tu experiencia y cómo los combinas en los comentarios.
