À medida que os objetos aumentam, o código pode virar uma teia. Quando o controlador de visualização, a rede, o cache e o logger de uma tela começam a chamar uns aos outros diretamente, corrigir um ponto quebra outro.
É aí que entram Mediator, Observer e Facade. Os três são apresentados como formas de “organizar a comunicação entre objetos”, mas resolvem problemas diferentes.
Mediator centraliza relações interligadas, Observer propaga mudanças de estado de um para muitos e Facade organiza internals complexos atrás de um ponto de entrada simples.
Lembrar desta frase já resolve metade. A seguir, veremos quando usar cada padrão, como eles diferem e o código de cada um.
Os três padrões em um resumo de uma linha
Aqui estão os pontos essenciais para consultar quando bater a dúvida.
- Mediator — Vários objetos se comunicam por meio de um mediador, sem referências diretas entre si
- Observer — Quando o estado de um objeto muda, todos os objetos inscritos recebem uma notificação automática
- Facade — Uma interface simples oculta um subsistema complexo
Mesmo quando todos “organizam a comunicação”, o foco de cada um é diferente.
Mediator reduz a complexidade das relações, Observer lida com a propagação de mudanças e Facade reduz a complexidade de uso.
Mediator vs. Observer: qual é a diferença?
Esses dois são os mais fáceis de confundir, porque ambos impedem chamadas diretas entre objetos.
A diferença está na direção da relação.
Observer tem uma direção clara. Quando um Subject muda, a atualização flui em um sentido para seus inscritos. Por exemplo, quando chega uma nova mensagem no chat, a tela, o badge de notificação e o som reagem separadamente.
No Mediator, as direções ficam interligadas. Ao tocar em um botão, um campo de texto é ativado, o que altera o estado do botão Salvar, e assim por diante. O mediador coordena essa relação de muitos para muitos.
// Observer: mudanças de estado se propagam em um 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("Badge do carrinho: \(count)") }
}
let cart = Cart()
cart.subscribe(Badge())
cart.items = 3
// Saída: badge do carrinho: 3Quando o carrinho muda, o badge o acompanha automaticamente. Cart não precisa saber o que é Badge.
Já no Mediator, o mediador mantém as regras entre os objetos.
// Mediator: o mediador gerencia regras interligadas
final class FormMediator {
var isAgreed = false
func agreedChanged(_ value: Bool, submit: Button) {
isAgreed = value
submit.isEnabled = value // Regra: ativar o envio somente após o consentimento
}
}
final class Button { var isEnabled = false }
let submit = Button()
let mediator = FormMediator()
mediator.agreedChanged(true, submit: submit)
print(submit.isEnabled)
// Saída: trueO checkbox e o botão não precisam conhecer um ao outro diretamente; o mediador aplica a regra “ativar o envio quando houver consentimento”.
Facade tem uma função um pouco diferente
Facade tem um objetivo diferente dos dois anteriores. Ele não coordena a comunicação; é um padrão que oculta internals complexos.
Imagine que, para processar um pedido, seja necessário chamar em sequência os módulos de pagamento, estoque, entrega e notificações. O código chamador fica confuso.
Facade reúne tudo atrás de um único ponto de entrada.
final class OrderFacade {
func placeOrder(_ id: String) {
Payment().charge(id)
Stock().reduce(id)
Delivery().book(id)
print("Pedido concluído: \(id)")
}
}
OrderFacade().placeOrder("A-1024")
// Saída: pedido concluído: A-1024Por fora, basta chamar placeOrder. Não importa quantos módulos existam internamente.
O ponto principal é este: Facade não faz objetos se comunicarem; ele simplifica a relação entre o chamador e o sistema complexo. A direção aponta para dentro.
Comparação rápida
Esta é a forma como os classifico na prática em 2026.
| Categoria | Mediator | Observer | Facade |
|---|---|---|---|
| Problema resolvido | Relações interligadas de muitos para muitos | Propagação de mudanças de estado | Ocultar internals complexos |
| Direção da relação | Interligadas (coordenação central) | Um para muitos (um sentido) | Chamador → sistema |
| Mudança no acoplamento | Menor acoplamento entre objetos | Separação entre sujeito e inscritos | Menor complexidade de uso |
| Exemplo típico | Validação de formulário, coordenação de chat | Notificações, vinculação de dados | API de integração de pagamentos e pedidos |
A tabela deixa claro que os três não se sobrepõem.
Quando usar e quando evitar
Padrões podem ser prejudiciais quando usados em excesso. Se você colocar todas as relações interligadas em um Mediator, ele pode facilmente virar um God object.
- Mediator — Use quando 3–4 objetos ou mais referenciarem uns aos outros diretamente e as regras estiverem interligadas. Se as regras forem simples, evite-o para não deixar o mediador grande demais.
- Observer — Use quando vários pontos precisarem saber de uma mudança em um só lugar. Cancele a inscrição ou poderá causar um vazamento de memória.
- Facade — Use quando quiser ocultar procedimentos de chamada complexos. Ele atrapalha quando o controle interno detalhado é indispensável.
Em uma frase: Mediator para relações interligadas, Observer para comunicar mudanças e Facade para ocultar procedimentos.
Como isso aparece em entrevistas
P. Qual é a diferença entre Mediator e Observer?
Observer é uma estrutura de um para muitos na qual as mudanças de estado de um Subject se propagam em um sentido para os inscritos. Mediator é uma estrutura de muitos para muitos na qual um mediador coordena centralmente as regras de interação entre objetos interligados. Direção e complexidade das relações são as principais diferenças.
P. Facade também reduz o acoplamento. Como ele difere do Mediator?
Facade coloca uma interface simples diante de um subsistema para reduzir a complexidade de uso entre o chamador e o sistema. Já Mediator coordena a comunicação entre objetos pares. Uma boa resposta é: Facade simplifica em um sentido; Mediator coordena interações.
Em vez de memorizar os três padrões, pergunte primeiro se seu código tem um “problema de relações interligadas”, um “problema de propagação de mudanças” ou um “problema de procedimentos complexos”. Quando a resposta estiver clara, o padrão virá naturalmente. Escolha apenas um para aplicar no refactoring de hoje.