"Facades" na vida real

Muitos profissionais de TI possuem ou já possuíram empresas abertas para prestação de serviços, pois muitos lugares trabalham com essa forma de contratação terceirizada. Mas depois se a pessoa muda para um trabalho onde seja contratado como CLT, manter uma empresa aberta pode gerar gastos mensais com sua manutenção que são desnecessários.

Para uma pessoa encerrar uma empresa são necessários vários passos burocráticos. Envolvem a interação com vários órgãos como Previdência Social, Junta Comercial, Receita Federal, prefeituras, entre outros (este link possui um resumo caso você tenha curiosidade http://www.sebrae.com.br/sites/PortalSebrae/artigos/Como-fechar-uma-empresa:-passo-a-passo-para-encerrar-as-atividades).

Mesmo sendo possível uma pessoa enfrentar toda essa burocracia e fazer todo o processo de encerramento sozinha, é muito mais prático contratar alguém especializado para fazer esse trabalho. Geralmente o próprio contador que manteve a empresa ativa durante o tempo em que a pessoa esteve contratada como PJ (pessoa jurídica).

Dessa forma todo o trabalho é terceirizado e a pessoa não tem que se preocupar com os detalhes para o encerramento da empresa. Ela só precisa solicitar ao contador, passar as informações necessárias para que ele desempenhe o trabalho, e aguardar o seu retorno.

Mas o que isso tem a ver com este post? Não, eu não vou ensinar aqui como encerrar uma empresa muito menos fazer propaganda de consultorias de contabilidade. Esse exemplo que eu dei é para ilustrar como funciona o design pattern Facade.

Este padrão é utilizado para simplificar a interação de objetos, provendo uma interface mais enxuta de forma que toda a complexidade fique invisível ao cliente. Entretanto ele é muito mal utilizado pois os desenvolvedores geralmente têm um conceito deturpado dele.

Isso geralmente ocorre em lugares onde se estabelece uma determinada arquitetura de sistemas que divide os componentes em camadas de dados, camada de negócio e a famigerada camada de fachada (facade). O problema é que os sistemas são construídos de forma anêmica, ou seja, essas camadas não possuem inteligência e se resumem a “tubos” para comunicação de forma ineficiente entre a interface (tela) e a base de dados.

Veja a imagem abaixo. É um exemplo de um sistema construído da forma que eu citei. Veja que as camadas intermediárias não tem muita função a não ser repetir a mesma assinatura de método, ligando uma tela com o banco de dados, provavelmente com uma chamada de uma stored procedure. Na ânsia em se manter uma arquitetura que a empresa adota, muitas vezes não se pensa a real utilidade do que se está construindo.

Agora como esse sistema deveria ser, para utilizar corretamente um padrão de facade? Bom, temos que resolver o problema acima onde toda a lógica de manipulação ficou a cargo da tela (ela verifica se existe o pedido, emite a fatura e controla o envio de e-mail). O componente de facade então deve ser o único ponto da funcionalidade que se quer executar.

Perceba que no novo diagrama, a regra de negócio já foi para o meio e a tela faz uma única chamada. Toda orquestração (e sua complexidade) ficou então isolada a partir da fachada. Este componente então começa a "espalhar" chamadas para outros pontos do sistema.

Claro que ainda há espaço para muitas melhorias. Esse cenário que eu expus foi motivado pela manutenção de um sistema antigo, ainda usando Web Forms. Entretanto, a mensagem que eu gostaria de passar aqui é cuidado no uso de padrões, em especial o facade, para que não acabe deixando um sistema mais difícil de se manter.