Façade
Façade (ou Fachada, em português) é um termo muito oriundo da área de Arquitetura.
A grosso modo, podemos entender como a parte de fora de uma construção, que isola o mundo exterior o mundo interior.
Quando levamos o conceito para a Engenharia de Software, focando a arquitetura/estrutura de um sistema, do ponto de vista de semântica, a ideia é a semelhante.
Estruturalmente falando, isolamos partes do sistema (sub-sistema) com o uso de uma fachada (façade) e somente através dela (passando por ela) é que temos acesso ao sub-sistema.
/* Quando me refiro a “sub-sistema” pode se tratar de várias coisas: uma classe/objeto, um conjunto de classes/objetos [biblioteca, framework, API etc.], um módulo de um sistema, um conjunto de webservices etc. Neste post vamos nos referir sempre a sub-sistema, para padronizar o uso do termo no texto e facilitar o entendimento. */
Façade – ou Fachada – é um Padrão de Projeto (Design Pattern) muito útil e recomendado para projetos de software. É um padrão de projeto estrutural.
/* Os Padrões de Projeto são divididos em três “categorias”: criacionais (utilizados na criação de objetos dentro de um sistema), estruturais (utilizados na estrutura do sistema) e comportamentais (utilizados no comportamento do sistema). */
Objetivo do Façade
Abaixo seguem alguns dos principais objetivos do uso do Façade, em projetos de software:
- Abstrair/simplificar a complexidade de um sub-sistema: “pedaços de software” geralmente são complexos, com muito código e muita lógica de difícil compreensão. Muitas das vezes quando usamos (consumimos) um destes pedaços não precisamos conhecer sua estrutura interna, pois nos interessa apenas usar os recursos disponíveis. Neste contexto, consumir um componente por exemplo, acessando apenas sua fachada, é muito mais simples do que consumir seus recursos diretamente, o que demanda entender a estrutura interna do “pedaço” consumido.
- Desacoplar o sistema, favorecendo a separação de responsabilidades: um sistema bem projetado tem que ser um sistema desacoplado, com suas partes independentes uma das outras. Um sistema com fraco acoplamento possui uma série de benefícios que são bons para todo mundo (o programador, o analista, o arquiteto, o testador, o cliente, o empresário etc.). Obs.: o Princípio da Responsabilidade Única deve ser mantra de todo analista. Por exemplo, se cada módulo do sistema possui uma fachada para acesso ao seu mundo interno, cada módulo pode ser mantido/distribuído/testado sem a necessidade de carregar-se consigo um mundo de dependências.
- Reduzir a dependência entre “pedaços” do sistema: quem já desenvolveu software “à moda antiga” sabe o problema que é ter que distribuir um sistema inteiro em função de uma alteração mínima de código, num mundo de milhares de linhas de código. O processo de distribuição é muitas vezes traumático; por causa de um ajuste num “if” é necessário rodar todo o processo de liberação de versão (para quem faz software atualmente basta pensar no problema que é separar/baixar/atualizar tudo num TFS, Nugget etc. por causa de um simples “if” refatorado). Utilizar o façade para isolar estruturalmente os módulos do sistema (ou sub-sistemas) reduz a dependência, dando condições de, como citado no parágrafo anterior, manter/distribuir/testar isoladamente a parte do sistema que sofreu o ajuste no “if”, sem ter que fazer o mesmo com as outras partes do sistema em função de uma alteração pontual.
- “Esconder” código sujo, inviável de refatorar: quando me refiro a “esconder” não quero dizer para “jogar a sujeira para debaixo do tapete”. É boa prática refatorar software! Mas nem sempre isso é possível, principalmente quando falamos de sistemas legados. Mas quando há algum espaço para tornar as coisas menos piores (desculpe a ironia, se pareceu assim), é super interessante construir fachadas para um sistema já existente, visando diminuir o acoplamento entre as partes, diminuindo as dependências e complexidade entre elas.
Visão estrutural do Façade
A imagem acima é a mais encontrada na internet quando pesquisamos pelo padrão de projeto Façade.
Basicamente, é um diagrama de classes que ilustra o isolamento de um conjunto de classes (Class1, Class2 e Class3), com uma fachada entre este sub-sistema e seus consumidores.
As classes Client1 e Client2 somente acessam as classes Class1, Class2 e Class3 através da classe Façade. Na fachada há um método chamado doSomething(), que quando acessado por Client1 e Client2, executa métodos das classes citadas.
/* Alguns analistas ficam na dúvida sobre implementar código nos métodos de uma fachada ou apenas expor os métodos e redirecionar as chamadas aos métodos de classes do sub-sistema. Ambas as possibilidades são pertinentes, apenas é bom usar bom senso. Uma fachada que possui todos os métodos de um sub-sistema expostos apenas para isolar o sub-sistema pode tornar-se muito complexa e difícil de compreender. */
Exemplo de uso
Na imagem acima podemos ver o sub-sistema ERP fazendo acesso direto ao sub-sistema CRM, onde a classe GeradorRelatorioGerencialNegocio do ERP acessa diretamente as classes ClienteNegocio, VendaNegocio e ProdutoNegocio do CRM. Neste contexto, há grande dependência/forte acoplamento entre os sub-sistemas e suas classes.
A seguir, vejamos como o uso do Façade se encaixa no contexto acima.
Podemos notar que agora há uma “camada” entre os sub-sistemas, isolando ambos. No sub-sistema ERP, na classe GeradorRelatorioGerencial não há mais acesso direto às classes do sub-sistema CRM. Desta forma ganhou-se na diminuição da dependência, na manutenção adequada da separação de responsabilidades, na diminuição do acoplamento e no aumento da coesão.
Concluindo
O padrão de projeto Façade é um padrão leve, simples e de excelente custo/benefício. Seu uso é altamente recomendável, principalmente pela simplicidade e eficiência na redução do acoplamento e aumento da coesão.
Abraços!