A medida que aumentan los objetos, el código puede convertirse en espagueti. Cuando el controlador de vista, la red, la caché y el logger de una pantalla empiezan a llamarse directamente, arreglar algo en un sitio rompe otra cosa.
Aquí aparecen Mediator, Observer y Facade. Los tres se presentan como formas de “organizar la comunicación entre objetos”, pero en realidad resuelven problemas distintos.
Mediator centraliza relaciones enredadas, Observer propaga cambios de estado de uno a varios y Facade oculta internals complejos tras un punto de entrada simple.
Con recordar esta línea ya tendrás la mitad hecha. A continuación veremos cuándo usar cada patrón, en qué se diferencian y cómo implementarlos.
Los tres patrones, resumidos en una línea
Aquí tienes lo esencial para volver a consultarlo cuando surjan dudas.
- Mediator — Varios objetos se comunican mediante un mediador, sin referenciarse directamente
- Observer — Cuando cambia el estado de un objeto, se notifica automáticamente a sus suscriptores
- Facade — Una interfaz simple oculta un subsistema complejo
Aunque los tres “organizan la comunicación”, su enfoque es distinto.
Mediator reduce la complejidad de las relaciones, Observer gestiona la propagación de cambios y Facade reduce la complejidad de uso.
Mediator vs. Observer: ¿cuál es la diferencia?
Son los dos que más se confunden, porque ambos evitan que los objetos se llamen directamente.
La diferencia está en la dirección de la relación.
Observer tiene una dirección clara. Cuando cambia un Subject, la actualización fluye en un solo sentido hacia sus suscriptores. Por ejemplo, al llegar un mensaje nuevo al chat, la pantalla, la insignia de notificación y el sonido reaccionan por separado.
En Mediator, las direcciones están entrelazadas. Al pulsar un botón se activa un campo de texto, que a su vez cambia el estado del botón Guardar, y así sucesivamente. El mediador coordina esta relación de varios a varios.
// Observer: los cambios de estado se propagan en un solo sentido
protocol Observer: AnyObject { func update(_ count: Int) }
final class Cart {
private var observers: [Observer] = []
var items = 0 { didSet { observers.forEach { $0.update(items) } } }
func subscribe(_ o: Observer) { observers.append(o) }
}
final class Badge: Observer {
func update(_ count: Int) { print("Insignia del carrito: \(count)") }
}
let cart = Cart()
cart.subscribe(Badge())
cart.items = 3
// Salida: insignia del carrito: 3Cuando cambia el carrito, la insignia lo refleja automáticamente. Cart no necesita saber qué es Badge.
En cambio, con Mediator, el mediador contiene las reglas entre los objetos.
// Mediator: el mediador gestiona las reglas entrelazadas
final class FormMediator {
var isAgreed = false
func agreedChanged(_ value: Bool, submit: Button) {
isAgreed = value
submit.isEnabled = value // Regla: activar el envío solo tras dar consentimiento
}
}
final class Button { var isEnabled = false }
let submit = Button()
let mediator = FormMediator()
mediator.agreedChanged(true, submit: submit)
print(submit.isEnabled)
// Salida: trueEl checkbox y el botón no necesitan conocerse directamente; el mediador aplica la regla “activar el envío cuando se dé consentimiento”.
Facade tiene un enfoque algo distinto
Facade se diferencia de los dos anteriores por su objetivo. No coordina la comunicación; es un patrón que oculta los internals complejos.
Supongamos que para procesar un pedido hay que llamar en secuencia a los módulos de pagos, inventario, envío y notificaciones. El código cliente se vuelve desordenado.
Facade agrupa todo tras un único punto de entrada.
final class OrderFacade {
func placeOrder(_ id: String) {
Payment().charge(id)
Stock().reduce(id)
Delivery().book(id)
print("Pedido completado: \(id)")
}
}
OrderFacade().placeOrder("A-1024")
// Salida: pedido completado: A-1024Desde fuera, basta con llamar a placeOrder. No importa cuántos módulos haya dentro.
La idea clave es esta: Facade no hace que los objetos se comuniquen; simplifica la relación entre el llamador y el sistema complejo. La dirección apunta hacia dentro.
Comparación rápida
Esta es la forma en que los clasifico en la práctica a fecha de 2026.
| Categoría | Mediator | Observer | Facade |
|---|---|---|---|
| Problema que resuelve | Relaciones entrelazadas de varios a varios | Propagación de cambios de estado | Ocultar internals complejos |
| Dirección de la relación | Entrelazadas (coordinación central) | Uno a varios (un solo sentido) | Llamador → sistema |
| Cambio en el acoplamiento | Menor acoplamiento entre objetos | Separación entre sujeto y suscriptores | Menor complejidad de uso |
| Ejemplo típico | Validación de formularios, coordinación de chats | Notificaciones, enlace de datos | API de integración de pagos y pedidos |
La tabla deja claro que los tres no se solapan.
Cuándo usarlos y cuándo evitarlos
Los patrones pueden ser perjudiciales si se abusan. Si agrupas todas las relaciones entrelazadas en un Mediator, el mediador puede convertirse fácilmente en un God object.
- Mediator — Úsalo cuando 3–4 objetos o más se referencien directamente y sus reglas estén entrelazadas. Si las reglas son simples, evítalo para que el mediador no crezca demasiado.
- Observer — Úsalo cuando varios lugares deban conocer un cambio ocurrido en uno. Cancela las suscripciones o podrías provocar una fuga de memoria.
- Facade — Úsalo para ocultar procedimientos de llamada complejos. Puede estorbar cuando necesitas un control interno detallado.
En una frase: Mediator para relaciones entrelazadas, Observer para comunicar cambios y Facade para ocultar procedimientos.
Así se plantea en una entrevista
P. ¿Cuál es la diferencia entre Mediator y Observer?
Observer es una estructura de uno a varios en la que los cambios de estado de un Subject se propagan en un solo sentido a sus suscriptores. Mediator es una estructura de varios a varios en la que un mediador coordina centralmente las reglas de interacción entre objetos entrelazados. La dirección y la complejidad de las relaciones son las diferencias clave.
P. Facade también reduce el acoplamiento. ¿En qué se diferencia de Mediator?
Facade coloca una interfaz simple delante de un subsistema para reducir la complejidad de uso entre el llamador y el sistema. Mediator, en cambio, coordina la comunicación entre objetos del mismo nivel. Una buena respuesta es: Facade simplifica en un sentido; Mediator coordina interacciones.
En lugar de memorizar los tres patrones, pregunta primero si tu código tiene un “problema de relaciones entrelazadas”, un “problema de propagación de cambios” o un “problema de procedimientos complejos”. Cuando tengas la respuesta, el patrón surgirá de forma natural. Elige uno y aplícalo en la refactorización de hoy.