O que o padrão Facade realmente faz no dia a dia
Você já viu alguém criar uma classe que é basicamente um wrapper enorme em volta de outras dez classes e chamar isso de "simplificação". É exatamente isso que o padrão Facade propõe fazer, só que com mais intencionalidade. A ideia é simples: expor uma interface unificada para um subsistema complexo, sem que o cliente precise saber dos detalhes internos. Na prática, isso significa que ao invés de seu código chamar diretamente um motor de busca, um serviço de cache, uma camada de persistência e um processador de dados, você empacota tudo isso dentro de uma única classe e ela cuida da orquestração. O restante do sistema só vê a fachada.
sobre o padrão facade assinale a alternativa correta
A alternativa correta sobre o padrão Facade é a que diz: ele fornece uma interface simplificada para um conjunto de interfaces em um subsistema, definindo uma interface de nível mais alto que facilita o uso do subsistema. As outras opções geralmente confundem Facade com Proxy, com Adapter, ou com Composite, então é importante saber distinguir. Uma opção incorreta comum afirma que Facade adiciona funcionalidades extras a um objeto existente. Isso é Proxy, não Facade. Outra armadilha frequente é dizer que Facade converte interfaces incompatíveis — isso seria Adapter. E quem fala que Facade permite construir objetos compostos recursivamente está descrevendo Composite.
Então, resumo rápido: Facade = simplificar o uso de um subsistema. Não é estruturar hierarquias, nem adicionar comportamentos dinâmicos, nem adaptar interfaces. É apenas uma porta de entrada bem organizada.
Como implementar na prática
Em um projeto real, a implementação costuma ser algo que você constrói de forma incremental. Começa sem padrão nenhum, com chamadas espalhadas por todo o código. Algum tempo depois, você percebe que cinco ou seis classes diferentes precisam interagir com o mesmo grupo de bibliotecas de forma consistente. Aí você cria a fachada. O exemplo mais trivial é uma aplicação web que precisa consultar um serviço externo, persistir os dados no banco e enviar uma notificação. Sem fachada, cada controller trata disso separadamente. Com fachada, você tem uma classe `PedidoServiceFacade` que aceita uma requisição e orquestra: valida, salva, notifica. O controller só chama `processar(pedido)`.
Em Java, ficaria algo assim:
public class PedidoFacade {
private final RepositorioPedidos repositorio;
private final Notificador notificador;
private final Validador validador;
public PedidoFacade(RepositorioPedidos repositorio,
Notificador notificador,
Validador validador) {
this.repositorio = repositorio;
this.notificador = notificador;
this.validador = validador;
}
public ResultadoProcessamento processar(Pedido pedido) {
if (!validador.efetuar(pedido)) {
return ResultadoProcessamento.rejeitado();
}
repositorio.salvar(pedido);
notificador.enviarConfirmacao(pedido);
return ResultadoProcessamento.aprovado();
}
}Não precisa ser bonito. Precisa funcionar e esconder o que não interessa para quem consome.
Um problema real que encontrei e como resolvi
Num projeto de logística, tínhamos uma fachada que orquestrava chamadas para três serviços de rastreamento diferentes — cada um com protocolo, schema e comportamento de erro distintos. A fachada estava funcionando, mas introduzia um gargalo: todas as requisições passavam pela mesma thread, esperando respostas síncronas de serviços que podiam levar de 2 a 8 segundos. O workaround foi simples, mas não óbvio à primeira vista. Em vez de modificar a fachada em si, criei um `CompletableFuture` por operação de rastreamento dentro do método de processamento, usando um pool de threads dedicado (`Executors.newFixedThreadPool(10)`). A fachada continuava com a mesma interface, mas as operações agora rodavam em paralelo. O tempo médio de resposta caiu de 6 segundos para cerca de 2,5 segundos.
O ponto importante é que a fachada em si não mudou de assinatura. A alteração foi interna, e os consumidores nem perceberam a diferença na interface pública.
👉 Clique no botão abaixo para saber mais sobre o assunto!
O que ninguém conta sobre Facade
O primeiro insight contra-intuitivo é que Facade não reduz complexidade, ele a um único ponto. Todo o complexity continua lá embaixo, só que concentrada na fachada. Se você não documentar bem o que cada método da fachada faz internamente, ela vira uma caixa-preta ingovernável. Em projetos que eu vi, fachadas mal mantidas acumulavam mais de 400 linhas em um único método, e ninguém tinha coragem de mexer. O segundo ponto é que Facade e Dependency Injection não combinam bem quando você tenta injetar dependências demais na própria fachada. Já vi classes com mais de oito construtores injetados, o que torna o teste unitário praticamente inviável sem um container DI pesado. A solução que funcionou foi separar: fachada pura, sem lógica de negócio, apenas encadeando chamadas. A lógica foi movida para serviços auxiliares que a fachada consumia.
Quando Facade não é a resposta certa
Facade não serve para tudo. Se você está enfrentando incompatibilidade de interfaces entre bibliotecas, use Adapter. Se precisa controlar acesso a um recurso, use Proxy. Se quer adicionar responsabilidades dinamicamente, use Decorator. Também não adianta criar uma fachada para um sistema que já é simples. Eu já vi desenvolvedores criarem uma camada de fachada só pra uma classe com dois métodos. Isso não é abstração, é overhead desnecessário.
Outro cenário onde Facade falha é quando o subsistema precisa ser exposto em partes, não de forma agregada. Se diferentes clientes precisam de subsets diferentes das funcionalidades, uma única fachada vai forçar todos a dependerem de tudo, o que quebra o princípio de responsabilidade única.
Questões de prova — pratique
Além da questão principal sobre o padrão Facade, é comum encontrar variações em provas de certificação e entrevistas. Aqui vão algumas nuances que caem frequentemente: Questão 1: O padrão Facade se relaciona com qual princípio de design?
Resposta: Princípio da Responsabilidade Única e Lei de Deméter. A fachada centraliza a responsabilidade de orquestrar o subsistema e evita que clientes conheçam múltiplas classes internas. Questão 2: Qual a principal diferença entre Facade e Proxy?
Resposta: Facade simplifica o acesso a um subsistema inteiro. Proxy controla o acesso a um único objeto. São padrões com propósitos diferentes, apesar de ambos serem estruturais. Questão 3: É possível combinar Facade com Factory Method?
Resposta: Sim, e é comum. Uma fachada pode ser criada via Factory Method para esconder a lógica de instanciação das classes do subsistema. Isso é útil quando a fachada precisa de dependências configuradas de formas distintas.
Veredito prático
Facade é um dos padrões mais subestimados e mais mal aplicados que existe. Quando bem usado, elimina acoplamento direto entre camadas e reduz drasticamente a curva de integração entre equipes. Quando usado de forma ingênua, vira uma classe de deuses que ninguém entende e ninguém quer tocar. A regra que eu sigo: se você precisa de mais de três chamadas encadeadas para completar uma operação comum, considere uma fachada. Se precisa de mais de uma, já pense em refatorar. E se a fachada tiver mais de cinquenta linhas por método, é hora de dividir responsabilidades antes que vire um problema.
