Sobre O Padrão Facade Assinale A Alternativa Correta

O que o padrãoFacade realmente resolve na prática

A maioria dos artigos ensina padrãoFacade como se fosse uma solução mágica para código bagunçado. Na realidade, é apenas uma camada de abstração que esconde complexidade desnecessária dentro de uma interface mais simples. Você provavelmente já viu isso no dia a dia sem notar. Um framework de pagamento que expõe um único método processar() enquanto por baixo tem SDKs de gateway, criptografia, log de auditoria e retry logic rodando em sequência. Isso éFacade puro. O conceito básico é simples demais para ser subestimado. Você cria uma classe que sabe como falar com cinco, dez ou vinte outras classes, e expõe apenas os métodos que o cliente realmente precisa. Nada mais. O resultado é código mais legível, sim, mas também código que esconde acoplamento indesejado.

sobre o padrão facade assinale a alternativa correta

Se você está se preparando para uma prova ou certificação, essa pergunta aparece com frequência. A alternativa correta sempre gira em torno da ideia de prover uma interface unificada para um conjunto de interfaces em um subsistema, reduzindo a complexidade percebida pelo cliente. Não se trata de criar novos comportamentos, nem de implementarbom design de herança. Trata-se de simplificar a comunicação. Eu tive um problema específico num projeto interno de integrações. Tinhamos um serviço de notificações que precisava mandar email, SMS e push notification ao mesmo tempo. Cada provedor tinha seu próprio SDK, suas próprias configurações de autenticacao, seus próprios formatos de erro. O código espalhado por toda a codebase virou uma bola de neve em semanas. A solucao foi criar uma classeFacade chamada Notificador que recebia todas as dependências no construtor e expunha apenas notify(destinatario, mensagem, tipo). O time inteiro passou a usar essa unica classe. A manutencao dos SDKs isolados ficou interna aoFacade. Isso reduziu o numero de dependencias diretas entre modulosem nosso projeto de aproximadamente 40 para 7 em dois dias.

Como implementar sem errar

A primeira coisa que as pessoas fazem errado é transformar oFacade em um deus. Ele acaba orchestrandofuncionalidades que nao tem nada a ver entre si só porque ficou conveniniente colocar tudo na mesma classe. Isso acontece quando voce nao consegue decidir onde termina oFacade e onde começa outra camada. A regra pratica que eu sigo é simples: se o metodo doFacade precisa de mais de três linhas de implementacao propria, provavelmente voce esta escondendo logica que deveria estar em outra classe. OFacade nao deve conter regras de negocio. Ele apenas direciona chamadas. Se voce precisar adicionar uma validacao antes de enviar uma notificacao, coloque em um service separado, nao noFacade. Se oFacade crescer demais, quebre-o em variosFacades menores, cada um responsavel por um subsistema diferente. É comum ver gente criar classes com mais de 500 linhas achando que estao seguindo o padrao. Isso não éFacade. Isso é um cheque-mestre mal disfarçado. Outro ponto importante: injeção de dependência. OFacade precisa conhecer os componentes do subsistema que vai simplificar. O jeito mais limpo é passar essas dependências pelo construtor. Evite instanciar os objetos diretamente dentro doFacade, senão você perde a capacidade de testar facilmente e ainda cria um acoplamento temporal que aparece só em runtime.

Vantagens e desvantagens reais

OFacade reduz o acoplamento direto entre o cliente e o subsistema complexo. Isso facilita a troca de implementações internas sem quebrar código externo. Em projetos grandes, onde múltiplos times trabalham em partes diferentes do sistema, essa separação evita que mudanças em um subsistema se propaguem como efeito dominó. Mas tem um custo. A cadaFacade que você adiciona, você introduz uma camada extra de indireção. Depurar bugs fica mais trabalhoso porque você precisa atravessar peloFacade antes de chegar ao código real. Além disso, se o subsistema tiver funcionalidades que oFacade não expõe, você fica limitado. Às vezes o cliente precisa de algo que está fora da interface simplificada, e a solução mais comum — e errada — é expandir oFacade com novos métodos, transformando-o numa interface genérica que perde todo o propósito original. Existe um caso extremo que eu vi acontecer: oFacade vira um wrapper automático gerado por ferramenta, expondo todos os métodos de todos os subsistemas sob um mesmo nome. Tecnicamente é umFacade, mas na prática é apenas um Namespace organizado. Isso não resolve nada e ainda piora a discoverability do código.

Quando usar e quando não usar

UseFacade quando um subsistema tiver muitas dependências complexas e o numero de clientes que precisam interagir com ele for grande. Também é útil quando voce quer isolarefeitos colaterais de mudancas em bibliotecas de terceiros. Uma integracao com API externa que muda frequentemente merece umFacade para que o resto do sistema nao precise ser atualizado a cada versionamento. Não useFacade quando o subsistema já é simples. Criar uma abstração extra para três classes que fazem uma coisa cada uma é overengineering. OFacade existe para reduzir complexidade percebida, não para aumentar o número de classes no projeto. Se você está adicionando umFacade e ele não está economizando linhas de código nos clientes, provavelmente está no caminho errado. Também eviteFacade em camadas de domínio puro. Entidades e value objects já deveriam ser autocontidos. Forçar umFacade entre domínio e infraestrutura pode mascarar problemas de design que seriam mais fáceis de resolver com composiçãocorreta.

Um exemplo concreto

Vamos supor um sistema de pedidos. O processo envolve calcular frete, aplicar desconto, verificar estoque, criar o registro no banco e enviar confirmação. SemFacade, cada um desses passos seria chamado diretamente pelo controlador ou service orquestrador. ComFacade, você tem uma classe PedidoFacade que recebe instâncias de FreteService, DescontoService, EstoqueService, BancoService e ConfirmacaoService, e expõe um único método criarPedido(dadosDoPedido). O controlador chama apenas uma vez. OFacade encadeia as chamadas na ordem correta, lida com exceções de cada subsistema de forma isolada, e retorna um resultado unificado. Se amanhã o provedor de frete mudar de SDK, você altera apenas o método correspondente dentro doFacade, sem tocar no resto do sistema. Isso é o valor real do padrão, longe dos diagramas UML dos livros.