O Padrão Facade aplicado

Veja neste arigo a utilização do padrão Facade.

Uma pequena introdução histórica antes de aplicarmos o Padrão Facade ou Façade (doravante Facade) em nosso projeto.

O conceito de Padrão de Projeto (Design Pattern) data da década de 70, e foi criado pelo arquiteto Christopher Alexander. Ele partiu do princípio que um Padrão deve ter as seguintes características:

Além de características, também definiu um formato que um Padrão deve possuir, em cinco partes:

O padrão Facade

O Padrão Facade que é simples de ser aplicado e que traz grandes benefícios aos projetos é dito como sendo um padrão estrutural e está entre os 23 padrões de projeto do GoF (Gang of Four).

Entende-se por padrão estrutural todo padrão de projeto que trata da associação entre classes e objetos.

Como o nome sugere Facade, é realmente uma fachada, podemos fazer a seguinte analogia, quando caminhamos em frente a um prédio com uma bela fachada, vemos as belas janelas as paredes bem decoradas, ou seja um ambiente bem amigável, e ignoramos toda a complexidade por trás da obra, a quantidade de salas, todas as empresas que estão neste prédio, deste modo o Facade também age nos projetos de software, dentre seus benefícios, alguns são:

>

Apresentando o problema

Partindo do princípio que temos uma aplicação que cadastra cliente, este cliente deve possuir um acesso ao sistema em área restrita, portanto ele também tem um usuário, e o banco de dados está bastante normalizado, onde o cliente possui também um endereço, a Figura 1, demonstra a proposta das entidades no sistema, sem os campos de cara uma.

Figura 1 – Proposta das entidades para cadastro de um cliente no sistema.

Como a aplicação está projetada em 03 camadas, com classes de visualização, objetos de negócio e persistência devidamente organizados e separados.

As regras de negócio envolvendo cada entidade criada, está devidamente separada em cada objeto de negócio responsável, centralizando assim as regras e definindo uma arquitetura robusta.

O cadastro completo do cliente é feito em uma única tela, ou seja, ela precisa utilizar 03 objetos de negócio (ClienteBO, UsuarioBO, EnderecoBO) para cadastrar um único cliente no sistema.

De modo que a representação desta arquitetura seria semelhante a Figura 2.

Figura 2 – Arquitetura da aplicação sem o Padrão Facade aplicado

Cabe a camada de visualização tratar todos as exceções e fazer as chamadas aos 03 objetos de negócio, mesmo que os Objetos de Negócios estejam muito bem projetos, a visualização vai ter que decidir por exemplo: usuário e endereço foram inseridos com sucesso, ou ainda, problemas na inserção do cliente é necessário rollback no endereço e no usuário.

E por enquanto não estamos levando a possibilidade de mudança na regra de negócio, pois não temos as chamadas centralizadas, elas estão em “n” objetos, em um cenário simples não representa tanto problema, porém é necessário termos consciência que é exponencial.

Proposta da solução

Conhecendo o problema, agora vamos levantar o que nossa arquitetura precisa melhorar:

A Figura 3, mostra a arquitetura com uma alteração pouco significativa em termos de trabalho, que agrega os benefícios acima.

Figura 3 – Arquitetura utilizando Facade

Pudemos perceber com a aplicação do Padrão Facade não importa quantas classes tenhamos na visualização ou no negócio, elas sempre irão interagir por um único caminho, mantendo a arquitetura coerente bom baixo acoplamento e com alta manutenabilidade.

Sua aplicação nos projetos já existentes não é de grande complexidade, por isso foi o escolhido para ser o primeiro padrão apresentado.

Na seção de links existe para download um exemplo em java da aplicação do Padrão Facade.

Links:

Padrão de Projeto: http://pt.wikipedia.org/wiki/Padr%C3%B5es_de_projeto_de_software

Exemplo em Java: http://www.fabiogodoy.com.br/facade

Artigos relacionados