DevMedia
Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Para efetuar o download você precisa estar logado. Clique aqui para efetuar o login

O Padrão Facade aplicado

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

[fechar]

Você não gostou da qualidade deste conteúdo?

(opcional) Você poderia comentar o que não lhe agradou?

Confirmo meu voto negativo


Breve história dos padrões de projeto

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:

 - Encapsulamento.

 - Generalidade.

 - Equilíbrio.

 - Abstração.

 - Abertura.

 - “Combinatoriedade”.

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

 - Nome.
 - Exemplo.
 - Contexto.
 - Problema.
 - Solução.

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:

 - Reduz a complexidade de uma api, liberando acesso a métodos de alto nível encapsulando os demais.
 - Produz uma interface comum e simplificada.
 - Pode encapsular uma ou mais interfaces mal projetadas em uma mais concisa.

 - Reduz drasticamente o acoplamento entre as camadas do projeto.

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.

pb_13_05_09_pic01.JPG
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.

pb_13_05_09_pic02.JPG
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:

 - Diminuir o acoplamento entre camadas.
 - Esconder a complexidade de 03 objetos de negócio para inserir um único cliente.
 - Tornar o código mais manutenível na medida em que as classes de visualização e negócio forem aumentando em quantidade.

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

pb_13_05_09_pic03.JPG
Figura 3
– Arquitetura utilizando Facade

Conclusão

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




Formado em sistemas de informação pela Universidade do Sul de Santa Catarina e atualmente analista de sistemas da Nexxera Tecnologias e Serviços S/A, onde coordena remotamente os trabalhos da fábrica de software da empresa. Possui [...]

O que você achou deste post?
Conhece a assinatura MVP?
Publicidade
Serviços

Mais posts