Arquitetura e Desenvolvimento de software — Parte 12 — Facade

E aí pessoal, como passaram as festas de final de ano?

Voltando a ativa, vamos ao primeiro post de 2019, continuando a série sobre design patterns. Hoje vamos aprender sobre o pattern Facade.


Facade

Este talvez seja um dos padrões mais conhecidos, ou não exatamente, e utilizados. Seu termo é diretamente relacionado a arquitetura, sendo uma “fachada”, literalmente.

Utilizamos quando queremos reduzir a complexidade de uma operação em um sistema, fornecendo um ponto de responsabilidade única para que um cliente consuma.

Vamos tomar como exemplo, a criação de uma venda, com itens selecionados com base em um catálogo de produtos.ade em estoque disponível.

Qual seria o processo para inserir esta venda no sistema? Cadastrar a venda na tabela de vendas e os itens na tabela de itens, cada item com sua chave extrangeira para a venda a qual pertencem. Estes itens são provenientes de um cadastro de produtos, cada um com seu Id. Já ficou um pouco complicado para o cliente ter que chamar cada uma destas operações, não é verdade? E se tivermos que repetir estes passos em outros setores / módulos do sistema? Como fica a manutenção, mesmo em pequenas modificações?

Com uma Facade, teríamos este processo escrito em um método de “fachada”, chamado IncluirVenda, por exemplo, que executaria este processo de cadastro para nós e retornaria apenas o resultado ou exceção caso alguma parte do processo falhasse. Ganhamos com isso a possibilidade de testar cada passo individualmente e ainda testar o processo como um todo. Inclusive, utilizar injeção de dependência (veremos em um artigo mais a frente) com este pattern facilita muito esta questão de testar nosso código.

Outra vantagem de uma Facade, é que podemos ter implementações diferentes, seguindo uma mesma interface. Imaginemos que temos uma VendaBalcao e VendaEntrega. O processo é semelhante, com exceção da questão de incluir entrega, postagem, rastreio, frete, transportadora, etc. Com a criação de uma Interface para a Facade, podemos combinar este pattern com o Strategy, onde temos processos diferentes, utilizados de acordo com a estratégia do momento, se é uma venda para entrega ou presencial.

Apenas como informação extra, vemos com grande frequência, classes de Serviços em nossas aplicações, sendo implementadas seguindo o modelo de uma Facade, para isolar o domínio e regras menores do cliente e ainda incluindo cada pequeno passo dentro de uma transação gerenciada pelo Service ou Facade. Vamos ver o diagrama UML na ficha resumo a seguir, assim evitamos ficar muito repetitivos, ok?

Resumindo, Facade é um pattern bem simples, responsável por encapsular sub-sistemas e processos em uma interface simples, facilitando o acesso de clientes a estes processos e reduzindo o acoplamento destes sub-sistemas entre os N clients que possamos ter.

Vamos a ficha resumo do pattern para finalizar.


Ficha Resumo

  • Nome: Facade;
  • Objetivo / intenção: Simplificar o uso de processos mais complexos e / ou que envolvam vários sub-sistemas em uma interface simples;
  • Motivação: Quando temos diversos sub-sistemas e / ou processos mais complexos e longos, fazer com que cada cliente precise fazer as devidas chamadas a cada “pedaço” do processo acaba tornando nosso sistema mais complexo de manter. Com o uso de uma interface simples,
  • Aplicabilidade: O padrão Facade é bastante utilizado quando queremos tornar nosso sistema mais fácil de manter, com menor acoplamento e dependência entre os N sistemas que temos com os clients. Um uso muito comum é a criação de Services, utilizando o modelo de um Facade, onde agrupamos o uso de repositories, gateways, etc., através de uma chamada e resposta simples a um método de interface.
  • Estrutura: No desenho abaixo, temos um exemplo UML de aplicação do pattern descrevendo o exemplo de venda que mencionamos antes. Detalhando cada parte, temos:
Representação UML do pattern Facade com o exemplo de Vendas que mencionamos.
Diagrama de sequência da Facade acionando cada um dos sub-sistemas, no caso, repositories.
  • Consequências: O pattern Facade auxilia muito isolando a complexidade em operações grandes e / ou que utilizam muitos sub-sistemas ou componentes diferentes de nossa aplicação, mas precisamos tomar muito cuidado, pois o mau uso pode acabar na criação de um “Facade Severino”, que acaba acumulando responsabilidades demais, quebranco o princípio de responsabilidade única. Em nosso exemplo, a função dele é inserir uma venda, sendo responsável pelos itens e atualização do estoque. A atualização do estoque em si já acaba sendo uma responsabilidade extra, que por boas práticas, deve ser colocada em outra Facade, assim como emitir notas, enviar o pedido por email, cada um para uma Facade diferente, evitando que o objeto torne-se impossível de manter.
  • Implementações: Abaixo temos um exemplo de código em C# para o pattern:
  • Usos conhecidos: Muito utilizado na construção de aplicações com uma quantidade grande de sub-sistemas utilizados em um mesmo processo, para abstrair esta complexidade fornecendo interfaces mais simples para que os módulos client possam acessar, reduzindo a complexidade e acoplamento de sistemas, assim como facilitando a manutenção, reuso e testabilidade do sistema.
  • Padrões relacionados: O padrão Abstract Factory pode ser usado com o Facade para fornecer uma interface responsavel por criar objetos em um subsistema de forma independente. O Mediator também é muito semelhante ao Facade, pois abstrai a funcionalidade de classes pré-existentes. No entanto, a proposito do Mediator é abstrair comunicação arbitraria entre objetos relacionados, comumente centralizando funcionalidades que não correspondem a nenhum deles. Classes relacionadas ao Mediator não só são cientes deste, como também se comunicam com ele diretamente ao invés de se comunicarem uma à outra

Concluindo e avisos extras

Este foi o padrão Facade, muito útil quando queremos encapsular processos mais complexos e / ou que utilizam muitos sub-sistemas em uma interface simples, reduzindo o acoplamento destes sub-sistemas com nossos clients e ainda facilitando a manutenção / refatoração de nossos projetos.

Na próxima parte da série iremos abordar o último padrão do grupo estrutura, Proxy.

E aproveitando para divulgar, dia 19 de Janeiro, teremos uma edição Brasileira do mega evento da Microsoft, o Microsoft Connect(); Brasil, organizado em SP pela comunidade DevelopersBR, onde vou palestrar sobre ASP.NET Core 2.2, utilizando o recurso de Health Check com Kubernetes.

O Connect(); é um dos mais importantes eventos da Microsoft, que acontece anualmente nos Estados Unidos, trazendo os principais anúncios e novidades quentinhas sobre o Microsoft Azure, diretamente da fonte.

Venha aprender com profissionais de referência do mercado sobre essas novidades, fazer muito network e tomar uma cerveja gelada no final do dia conosco.

O evento é GRATUITO e para se inscrever, basta acessar o link no Meetup:
https://www.meetup.com/DevelopersBR/events/257187406/

Quem precisar de certificado por favor se inscrever também no link do Sympla: https://www.sympla.com.br/microsoft-connect-brasil__427973

Um abraço a todos e até a próxima.