Esse artigo faz parte da revista Java Magazine edição 28. Clique aqui para ler todos os artigos desta edição

AN style="FONT-SIZE: 10pt; BACKGROUND: white; COLOR: red; FONT-FAMILY: Verdana; moz-background-clip: -moz-initial; moz-background-origin: -moz-initial; moz-background-inline-policy: -moz-initial">

Atenção: por essa edição ser muito antiga não há arquivo PDF para download.Os artigos dessa edição estão disponíveis somente através do formato HTML.

De Volta aos Patterns

Visitor, Façade e mais sobre Command

Saiba como criar sistemas mais flexíveis com pattern que facilitam operações sobre estruturas heterogêneas e centralizam o acesso a funcionalidades

 

O cliente surge na sala de desenvolvimento; o temor se espalha pela equipe. Mais um relatório ou entidade? O último “contorno” no código vai resistir? Lidar com mudanças é um grande desafio, e mudanças em requisitos podem implicar num esforço de analise e design, codificação, testes, novos bugs – e desconforto na equipe.

O objetivo deste artigo é mostrar como utilizar alguns padrões de projeto para diminuir o impacto da introdução de novas funcionalidades durante o desenvolvimento. Para cada pattern, será indicando a maneira que ele promove a flexibilidade e apresentado um exemplo pratico de como pode ser aplicado.

 

Cenário de exemplo

Para exemplificar o uso dos patterns, nos basearemos numa empresa fictícia: um intermediário comercial. Nossa empresa é remunerada por fornecedores para divulgar ofertas de produtos para os varejistas; e pelos varejistas para das acesso a catálogos de produtos com as ofertas mais recentes. Assim, os fornecedores simplificam a distribuição e expandem o acesso ao varejo; e os varejistas podem consultar catálogos sempre atualizados, comparar ofertas e escolher fornecedores seguindo vários critérios.

Nesse cenário latamente dinâmico, será comum a necessidade de personalizações e extensões, como por exemplo novos relatórios, regras adicionais e customizações de funcionalidades existentes. Um prato cheio de uso de patterns.

Vamos começar definindo os elementos principais do negocio. O diagrama de classes inicial é mostrado na Figura 1 (com getters e setters omitidos): nele são representados as entidades, sobre as quais serão realizadas as principais operações do sistema. As classes Produto, Oferta, Catálogo, Fornecedor e Varejista surgem diretamente de uma análise do cenário proposto; as classes abstratas EntidadeBase e PessoaJuridica visam apenas à reutilização de códigos.

 

Figura 1. Entidades do exemplo

 

Operações de negócio e Command

...

Quer ler esse conteúdo completo? Tenha acesso completo