37
Padrões de Projeto Aplicações empresariais são complexas Existem várias formas possíveis de tratar tal complexidade, mas todas podem ser agrupadas em dois princípios: utilizar abordagens comprovadamente funcionais e antecipar necessidades futuras. Em ambos os casos, existem técnicas comuns que transcendem um sistema individual. Essas técnicas são conhecidas como design patterns.

Padrões de Projeto Aplicações empresariais são complexas Existem várias formas possíveis de tratar tal complexidade, mas todas podem ser agrupadas em dois

Embed Size (px)

Citation preview

Page 1: Padrões de Projeto Aplicações empresariais são complexas Existem várias formas possíveis de tratar tal complexidade, mas todas podem ser agrupadas em dois

Padrões de Projeto

Aplicações empresariais são complexas

Existem várias formas possíveis de tratar tal complexidade, mas todas podem ser agrupadas em dois princípios: utilizar abordagens comprovadamente funcionais e antecipar necessidades futuras. Em ambos os casos, existem técnicas comuns que transcendem um sistema individual. Essas técnicas são conhecidas como design patterns.

Page 2: Padrões de Projeto Aplicações empresariais são complexas Existem várias formas possíveis de tratar tal complexidade, mas todas podem ser agrupadas em dois

Padrões de Projeto (Design Patterns)

Definição

“Os padrões de projeto são descrições de objetos que se comunicam e classes que são customizadas para resolver um problema genérico de design em um contexto específico"

A idéia dos design patterns é capturar experiências comprovadamente corretas em desenvolvimento de software e ajudar a promover a prática de projeto correto. Cada pattern trabalha com um problema específico e recorrente no projeto ou implementação de softwares.

Page 3: Padrões de Projeto Aplicações empresariais são complexas Existem várias formas possíveis de tratar tal complexidade, mas todas podem ser agrupadas em dois

Design Patterns (Vantagens)

1. Esses patterns podem ser usados repetidas vezes, facilitando a incorporação da experiência de desenvolvimentos anteriores em novos projetos;

2. Patterns também fornecem uma linguagem comum para a discussão de arquitetura de software em um nível mais elevado;

3. Diminuem o tempo e o custo de projeto;

Page 4: Padrões de Projeto Aplicações empresariais são complexas Existem várias formas possíveis de tratar tal complexidade, mas todas podem ser agrupadas em dois

GOF Design Patterns

Em 1994, liderados por Erich Gamma a GOF (Gang of Four) - Erich Gamma, Richard Helm, Ralph Johnson a John Vlissides publicaram o livro que deu origem à onda dos Patterns na área de informática, Design Patterns: Elements of Reusable Object-Oriented Software.

O primeiro catálogo bem descrito sobre patterns de projeto para programas orientados a objeto. Neste livro eles apresentam 23 padrões de projeto úteis.

Page 5: Padrões de Projeto Aplicações empresariais são complexas Existem várias formas possíveis de tratar tal complexidade, mas todas podem ser agrupadas em dois

Classificação dos Design Patterns

Os patterns foram classificados pelo GOF de duas formas por proposta e por escopo;

A mais famosa é a por proposta, onde os patterns são classificados como de criação, comportamento e estrutura;

Os padrões de criação são aqueles que abstraem o processo de instanciação de objetos. Eles são ligados as instâncias e definem quais classes devem ser instanciadas ou não.

Os padrões de estrutura são aqueles que se ocupam da alteração da estrutura do de objetos e classes no que diz respeito a sua composição no sistema.

Os padrões de comportamento são aqueles que cuidam do controle do comportamento de classes ou objetos. São patterns dinâmicos que se ocupam de como a responsabilidade está distribuída no sistema.

Page 6: Padrões de Projeto Aplicações empresariais são complexas Existem várias formas possíveis de tratar tal complexidade, mas todas podem ser agrupadas em dois

Classificação dos Design Patterns

Escopo

Propósito

Classe

Objeto

Factory Method Class AdapterInterpreter

Template Method

Criação Estrutura Comportamento

Abstract FactoryBuilder

PrototypeSingleton

Object AdapterBridge

CompositeDecoratorFacade

FlyweightProxy

Chain of ResponsibilityCommand

IteratorMediatorMementoObserver

StateStrategyVisitor

Page 7: Padrões de Projeto Aplicações empresariais são complexas Existem várias formas possíveis de tratar tal complexidade, mas todas podem ser agrupadas em dois

Padrões de Criação

Factory MethodDefine uma interface para criar um objeto, mas deixar que subclasses decidam que classe instanciar.

Quando utilizar1.Quando uma classe (o criador) não pode antecipar a classe dos objetos que deve criar;

2.Quando uma classe quer que suas subclasses especifiquem os objetos criados;

3.Quando classes delegam responsabilidade para uma entre várias subclasses de apoio e queremos localizar num ponto único a conhecimento de qual subclasse está sendo usada.

Page 8: Padrões de Projeto Aplicações empresariais são complexas Existem várias formas possíveis de tratar tal complexidade, mas todas podem ser agrupadas em dois

Padrões de Criação

Abstract Factory Define uma interface para criar um objeto, mas deixar que subclasses decidam que classe instanciar.

Quando utilizar1.Quando uma classe (o criador) não pode antecipar a classe dos objetos que deve criar;

2.Quando uma classe quer que suas subclasses especifiquem os objetos criados;

3.Quando classes delegam responsabilidade para uma entre várias subclasses de apoio e queremos localizar num ponto único a conhecimento de qual subclasse está sendo usada.

Page 9: Padrões de Projeto Aplicações empresariais são complexas Existem várias formas possíveis de tratar tal complexidade, mas todas podem ser agrupadas em dois

Padrões de Criação

Builder Separar a construção de objeto complexo da

representação para criar representações diferentes com mesmo

processo. Quando Utilizar1. Use-o quando o algoritmo para criar um objeto

complexo precisar ser independente das partes que compõem o objeto e da forma como o objeto é construído.

2. Use quando o processo de construção precisar suportar representações diferentes do objeto que está sendo construído  

Page 10: Padrões de Projeto Aplicações empresariais são complexas Existem várias formas possíveis de tratar tal complexidade, mas todas podem ser agrupadas em dois

Padrões de Criação

SingletonGarantir que uma classe só tenha uma única instância, e

prover um ponto de acesso global a ela.

Quando utilizar 1. Quando se deseja que haja uma única instância de

uma determinada classe, permitindo que seja acessada por seus Clientes de forma global (ou seja, em qualquer ponto do código).

2. Quando se deseja que o número de instâncias de uma determinada classe seja controlado e/ou limitado.

Page 11: Padrões de Projeto Aplicações empresariais são complexas Existem várias formas possíveis de tratar tal complexidade, mas todas podem ser agrupadas em dois

Padrões de Criação

PrototypeEspecificar os tipos de objetos a serem criados usando uma instância como protótipo e criar novos objetos ao copiar este protótipo.

Quando utilizarCriar um objeto novo, mas aproveitar o estado previamente existente em outro objeto.

Page 12: Padrões de Projeto Aplicações empresariais são complexas Existem várias formas possíveis de tratar tal complexidade, mas todas podem ser agrupadas em dois

Padrões de Criação

Factory MethodDefine uma interface para criar um objeto, mas deixar que subclasses decidam que classe instanciar.

Quando utilizar1.Quando uma classe (o criador) não pode antecipar a classe dos objetos que deve criar;

2.Quando uma classe quer que suas subclasses especifiquem os objetos criados;

3.Quando classes delegam responsabilidade para uma entre várias subclasses de apoio e queremos localizar num ponto único a conhecimento de qual subclasse está sendo usada.

Page 13: Padrões de Projeto Aplicações empresariais são complexas Existem várias formas possíveis de tratar tal complexidade, mas todas podem ser agrupadas em dois

Padrões de Criação

Factory MethodDefine uma interface para criar um objeto, mas deixar que subclasses decidam que classe instanciar.

Quando utilizar1.Quando uma classe (o criador) não pode antecipar a classe dos objetos que deve criar;

2.Quando uma classe quer que suas subclasses especifiquem os objetos criados;

3.Quando classes delegam responsabilidade para uma entre várias subclasses de apoio e queremos localizar num ponto único a conhecimento de qual subclasse está sendo usada.

Page 14: Padrões de Projeto Aplicações empresariais são complexas Existem várias formas possíveis de tratar tal complexidade, mas todas podem ser agrupadas em dois

Padrões de Criação

Factory MethodDefine uma interface para criar um objeto, mas deixar que subclasses decidam que classe instanciar.

Quando utilizar1.Quando uma classe (o criador) não pode antecipar a classe dos objetos que deve criar;

2.Quando uma classe quer que suas subclasses especifiquem os objetos criados;

3.Quando classes delegam responsabilidade para uma entre várias subclasses de apoio e queremos localizar num ponto único a conhecimento de qual subclasse está sendo usada.

Page 15: Padrões de Projeto Aplicações empresariais são complexas Existem várias formas possíveis de tratar tal complexidade, mas todas podem ser agrupadas em dois

Padrões de Estrutura

AdapterConverter a interface de uma classe em outra interface esperada pelos clientes. Adapter permite a comunicação entre classes que não poderiam trabalhar juntas devido à incompatibilidade de suas interfaces.

Quando utilizar1. Sempre que for necessário adaptar uma interface para um cliente da Classe Adapter2. Quando houver uma interface que permita a implementação estática Objeto Adapter3. Quando menor acoplamento for desejado4. Quando o cliente não usa uma interface Java ou classe abstrata que possa ser estendida

Page 16: Padrões de Projeto Aplicações empresariais são complexas Existem várias formas possíveis de tratar tal complexidade, mas todas podem ser agrupadas em dois

Padrões de Estrutura

FaçadeOferecer uma interface única para um conjunto de interfaces de um subsistema. Façade define uma interface de nível mais elevado que torna o subsistema mais fácil de usar.

Quando UtilizarSempre que for desejável criar uma interface para um conjunto de objetos com o objetivo de facilitar o uso da aplicação.

Page 17: Padrões de Projeto Aplicações empresariais são complexas Existem várias formas possíveis de tratar tal complexidade, mas todas podem ser agrupadas em dois

Padrões de Estrutura

CompositeCompor objetos em estruturas de árvore para representar hierarquias todo-parte. Composite permite que clientes tratem objetos individuais e composições de objetos de maneira uniforme.

Quando UtilizarSempre que houver necessidade de tratar um conjunto como um indivíduo

Page 18: Padrões de Projeto Aplicações empresariais são complexas Existem várias formas possíveis de tratar tal complexidade, mas todas podem ser agrupadas em dois

Padrões de estrutura

BridgeDesacoplar uma abstração de sua implementação para

que os dois possam variar independentemente.

Quando Utilizaro Quando for necessário evitar uma ligação permanente entre

a interface e implementação

o Quando alterações na implementação não puderem afetar clientes

o Quando tanto abstrações como implementações precisarem ser capazes de suportar extensão através de herança

o Quando implementações são compartilhadas entre objetos desconhecidos do cliente

Page 19: Padrões de Projeto Aplicações empresariais são complexas Existem várias formas possíveis de tratar tal complexidade, mas todas podem ser agrupadas em dois

Padrões de Estrutura

DecoratorAnexar responsabilidades adicionais a um objeto dinamicamente. Decorators oferecem uma alternativa flexível ao uso de herança para estender uma funcionalidade.

Quando UtilizarEm Java, o uso mais comum de decoradores é nos objetos que representam fluxos de entrada e saída (I/O streams).

Page 20: Padrões de Projeto Aplicações empresariais são complexas Existem várias formas possíveis de tratar tal complexidade, mas todas podem ser agrupadas em dois

Padrões de Estrutura

FlyWeightUsar compartilhamento para suportar grandes quantidades de objetos refinados eficientemente.

Quando Utilizaro Quando o tamanho do conjunto de objetos for significativamente menor que a quantidade de vezes em que eles são usados na aplicação.o Quando objetos podem ser usados em diferentes contextos ao mesmo tempo (agindo sempre como um objeto independentemente).

Page 21: Padrões de Projeto Aplicações empresariais são complexas Existem várias formas possíveis de tratar tal complexidade, mas todas podem ser agrupadas em dois

Padrões de Estrutura

ProxyProver um substituto ou ponto através do qual um objeto possa controlar o acesso a outro.

Quando UtilizarA aplicação mais comum é em objetos distribuídos.

Page 22: Padrões de Projeto Aplicações empresariais são complexas Existem várias formas possíveis de tratar tal complexidade, mas todas podem ser agrupadas em dois

Padrões de Comportamento

Chain of ResponsibilityEvita acoplar o remetente de uma requisição ao seu destinatário ao dar a mais de um objeto a chance de servir a requisição. Compõe os objetos em cascata e passa a requisição através da cadeia até que um objeto seja capaz de atende-la.

Quando Utilizaro Quando for necessário que vários objetos possam servir a uma requisição ou repassá-la.o Quando for necessária a divisão de responsabilidades de forma transparente

Page 23: Padrões de Projeto Aplicações empresariais são complexas Existem várias formas possíveis de tratar tal complexidade, mas todas podem ser agrupadas em dois

Padrões de Comportamento

ObserverDefinir uma dependência um-para-muitos entre objetos para que quando um objeto mudar de estado, todos os seus dependentes sejam notificados e atualizados automaticamente. Quando UtilizarQuando for necessário garantir que objetos que dependem de outros fiquem em dia com mudanças de estado que ocorram.

Page 24: Padrões de Projeto Aplicações empresariais são complexas Existem várias formas possíveis de tratar tal complexidade, mas todas podem ser agrupadas em dois

Padrões de Comportamento

MediatorDefinir um objeto que encapsula como um conjunto de objetos interage. Mediator promove acoplamento fraco ao manter objetos que não se referem um ao outro explicitamente, permitindo variar sua interação independentemente.

Quando UtilizarQuando for necessário viabilizar que um grupo de objetos se comunique entre si sem que haja acoplamento entre eles.

Page 25: Padrões de Projeto Aplicações empresariais são complexas Existem várias formas possíveis de tratar tal complexidade, mas todas podem ser agrupadas em dois

Padrões de Comportamento

Template MethodDefinir o esqueleto de um algoritmo dentro de uma operação, deixando alguns passos a serem preenchidos pelas subclasses. Template Method permite que suas subclasses redefinam certos passos de um algoritmo sem mudar sua estrutura.

Quando UtilizarQuando a estrutura fixa de um algoritmo puder ser definida pela superclasse deixando certas partes para serem preenchidos por implementações que podem variar

Page 26: Padrões de Projeto Aplicações empresariais são complexas Existem várias formas possíveis de tratar tal complexidade, mas todas podem ser agrupadas em dois

Padrões de Comportamento

StatePermitir a um objeto alterar o seu comportamento quanto o seu estado interno mudar. O objeto irá aparentar mudar de classe.

Quando UtilizarQuando houver a necessidade de usar objetos para representar estados e polimorfismo para tornar a execução de tarefas dependentes de estado transparentes.

Page 27: Padrões de Projeto Aplicações empresariais são complexas Existem várias formas possíveis de tratar tal complexidade, mas todas podem ser agrupadas em dois

Padrões de Comportamento

StrategyDefinir uma família de algoritmos, encapsular cada um, e fazê-los intercambiáveis. Strategy permite que algoritmos mudem independentemente entre clientes que os utilizam.

Quando Utilizaro Quando classes relacionadas forem diferentes apenas no seu comportamentoo Strategy oferece um meio para configurar a classe com um entre vários comportamentoso Quando você precisar de diferentes variações de um mesmo algoritmoo Quando um algoritmo usa dados que o cliente não deve conhecero Quando uma classe define muitos comportamentos, e estes aparecem como múltiplas declarações condicionais em suas operaçõeso Strategy permite implementar as operações usando polimorfismo

Page 28: Padrões de Projeto Aplicações empresariais são complexas Existem várias formas possíveis de tratar tal complexidade, mas todas podem ser agrupadas em dois

Padrões de Comportamento

CommandEncapsular uma requisição como um objeto, permitindo que clientes parametrizem diferentes requisições, filas ou requisições de log, e suportar operações reversíveis.

Quando UtilizarParametrizar objetos por uma ação a realizar, como objetos MenuItem.Especificar, enfileirar e executar pedidos em tempos diferentes. Suportar ‘undo’ (desfazer). Estruturar um sistema em volta de operações de alto nível construídas sobre operações primitivas.

Page 29: Padrões de Projeto Aplicações empresariais são complexas Existem várias formas possíveis de tratar tal complexidade, mas todas podem ser agrupadas em dois

Padrões de Comportamento

IteratorProver uma maneira de acessar os elementos de um objeto agregado seqüencialmente sem expor sua representação interna. Quando UtilizarQuando existe um conjunto de objetos (coleção) e é necessário implementar um método de percorrê-la.

Page 30: Padrões de Projeto Aplicações empresariais são complexas Existem várias formas possíveis de tratar tal complexidade, mas todas podem ser agrupadas em dois

Padrões de Comportamento

VisitorRepresentar uma operação a ser realizada sobre os elementos de ma estrutura de objetos. Visitor permite definir uma nova operação sem mudar as classes dos elementos nos quais opera.

Quando UtilizarQuando for necessário:Plugar nova funcionalidade em objetos sem precisar mexer na estrutura de herança;Agrupar e manter operações relacionadas em uma classe e aplicá-las, quando conveniente, a outras classes (evitar espalhamento e fragmentação de interesses);Implementar um Iterator para objetos não relacionados através de herança.

Page 31: Padrões de Projeto Aplicações empresariais são complexas Existem várias formas possíveis de tratar tal complexidade, mas todas podem ser agrupadas em dois

MementoSem violar o encapsulamento, capturar e externalizar o estado interno de um objeto para que o objeto possa ter esse estado restaurado posteriormente. Quando UtilizarUse Memento quando:o Um snapshot do (parte do) estado de um objeto precisa ser armazenada para que ele possa ser restaurado ao seu estado original posteriormente;o Uma interface direta para se obter esse estado iria expor detalhes de implementação e quebrar o encapsulamento do objeto.

Padrões de Comportamento

Page 32: Padrões de Projeto Aplicações empresariais são complexas Existem várias formas possíveis de tratar tal complexidade, mas todas podem ser agrupadas em dois

Composite

Builder

Criação deComposites

Decorator

Adição deresponsabilidades

à objetos

Iterator

Enumeraçãode Itens

Flyweight

Interpreter

Visitor

Compartilhamentodos composites

Adição de Operações

Definição deuma Linguagem

Command

Chain ofResponsability

É compostopor

Definição da cadeia

Proxy

Adapter

Bridge

Adição de Operações

Definição deCaminhos

CompartilharSímbolosTerminais

Memento

SalvarEstado daIteração

Strategy

Mudança deapresentação

porconteúdo

Compartilhamentode estratégias

State

Compartilhamentode estados

PrevenirHisterese

Observer

Mediator

Gerência deDependências

Complexas

TemplateMethod

Definiçãode estados do

algorítimo

FactoryMethod

Utiliza

AbstractFactory

É implementadoUtilizando

Singleton

Instanciado Unicamente

Façade

Instanciado Unicamente

Prototype

Configuraçãodinâmicado Factory

Page 33: Padrões de Projeto Aplicações empresariais são complexas Existem várias formas possíveis de tratar tal complexidade, mas todas podem ser agrupadas em dois

J2EE Design Patterns

No mundo do J2EE, existem geralmente três camadas: a camada de apresentação, uma aplicação Web construída ou com servlets Java ou com Java Server Pages (JSP), uma camada de lógica de negócio construída em Session Enterprise Java Beans (EJB) e/ou classes e uma camada de dados que acessa um servidor qualquer de persistência seja com um Entity EJB ou alguma solução de mapeamento O/R.

Os patterns a seguir ajudam o desenvolvedor a melhorar a performance de seus sistemas em multi-camadas e torná-los mais fáceis de se manter ao reduzir a complexidade

Page 34: Padrões de Projeto Aplicações empresariais são complexas Existem várias formas possíveis de tratar tal complexidade, mas todas podem ser agrupadas em dois

J2EE Design Patterns

Camada de Apresentação

Camada de Lógica de Negócio

Camada de Dados

Page 35: Padrões de Projeto Aplicações empresariais são complexas Existem várias formas possíveis de tratar tal complexidade, mas todas podem ser agrupadas em dois

Design Patterns da Camada de Apresentação

Decorating FilterFacilita o pós e o pré processamento do request e response.Font ControllerDisponibiliza um controller central para gerenciar o requestView HelperEncapsula a lógica que está relacionada a formatação da apresentação nos componentes HelperComposite ViewCriar um objeto view a sub-componentes atômicos. Service To WorkerCombina um componente de dispatcher com um FrontController and View Helper Patterns.Dispatcher ViewUma variante do pattern Service to Work

Page 36: Padrões de Projeto Aplicações empresariais são complexas Existem várias formas possíveis de tratar tal complexidade, mas todas podem ser agrupadas em dois

Design Patterns da Camada de Lógica de Negócio

- Business Delegate Desacopla a camada de apresentação da camada de negócio e disponibiliza uma interface de façade e proxy para a camada de negócio.-Value Object Transporta dados entre as camadas.- Session Façade Esconde a complexidade do objeto de negócio centralizando o manuseio do processamento. - Aggregate Entity represents a best practice for designing coarse-grained entity beans.- Value Object Assembler Monta composite value object a partir de múltiplos repositórios de dados.- Value List Handler Gerencia a execução da query, o cache do resultado e do processamento-Service Locator Encapsula a complexidade do processo de lookup e criação e alocação de factories de serviços de negócios.

Page 37: Padrões de Projeto Aplicações empresariais são complexas Existem várias formas possíveis de tratar tal complexidade, mas todas podem ser agrupadas em dois

Design Patterns da Camada de Lógica de Dados

-Data Access Object Cria uma abstração dos data sources e fornece um acesso transparente aos dados. Service Activator Facilita o processamento assíncrono para componentes EJB.