design patterns quais padrões ainda sobrevivem com as novas tecnologias?

Globalcode – Open4Education1

Design PatternsQuais padrões ainda sobrevivem com as novas

tecnologias?

Rodrigo Cândido da SilvaInstrutor VOffice / Globalcode


Objetivo

> Realizar uma introdução sobre padrões de projetos e demonstrar alguns padrões

existentes no catálogo GoF e Core J2EE.


Agenda

> Introdução> GoF Patterns> Core J2EE Patterns> Conclusões> Perguntas e Respostas


Introdução

> Design pattern é...> Uma forma padrão de organizar classes e objetos;> Nomes para soluções que você já modelou;> Uma forma de compartilhar conhecimentos sobre

POO;> Soluções POO para problemas que incidem em

diversos cenários de desenvolvimento;> Uma definição de conjunto finito de responsabilidades

para uma classe;


Introdução

> Ao adotar design-patterns...> Seu código fica mais organizado;> Aumenta a qualidade;> Diminui a complexidade;> Facilita a comunicação dentro da equipe;> Facilita a ambientação de novos membros na equipe;> Aprende com a experiência dos outros.


Como surgem padrões?

ProblemaProblema

Contextualização

SoluçãoSolução

Benefícios

Padrões Relacionados

Consequências

Direciona


Como documentá-los?

> Elementos de um padrão...> Nome> Problema

> Quando aplicar o padrão, em quais condições?

> Solução> Como usar os recursos disponíveis (classes e objetos) para

solucionar o problema contextualizado.

> Benefícios> Conseqüências

> Custos de utilização> Impactos na flexibilidade, portabilidade, performance, etc.

> Padrões relacionados


Família de Padrões

> Existem algumas famílias conhecidas de padrões...> GoF (Gang of Four)> Core J2EE Patterns> GRASP> POSA> Enterprise Integration Patterns> SOA Patterns> etc.


GoF Patterns

> Surgiram em 1995 com a publicação do livro “Design Patterns: Elements of Reusable Object-Oriented Software”;

> Devido ao livro possuir 4 autores, este catálogo de padrões ficou popularmente conhecimento como GoF (Gang of Four);

> Define uma lista com 23 padrões de projeto;

> A publicação deste livro é considerado um marco na evolução e utilização de padrões de projetos dentro dos processos de desenvolvimento de software.


GoF Patterns

Comportamento

Cria

ção E

strutura

Classificação Sugerida


Abstract Factory

> Prover uma interface para criação de famílias de objetos relacionados ou dependentes sem especificar suas classes concretas.

> Benefícios> Promover o desacoplamento

entre classes da aplicação;> Abstrair a lógica de criação e

inicialização dos objetos;> Tornar facilitada a possível

troca entre famílias de objetos.


Abstract Factory


Singleton

> Garantir para que uma determinada classe do sistema terá somente um número determinado de instâncias (objeto) criadas, provendo um ponto de acesso global a mesma.

> Benefícios> Controlar o acesso as instâncias da

classe;> Reduzir a utilização desnecessária de

memória;> Fornecer mais flexibilidade que a

utilização de estruturas estáticas;> Habilita ter subclasses.


Singleton


Prototype

> Criar tipo de objetos diferentes, usando como base um protótipo (instância de um objeto com estrutura semelhante).


Prototype

Problema

Solução


Mediator

> Definir um objeto que encapsula o modelo como um conjunto de objetos interagem entre si, promovendo o fraco acoplamento.

> Benefícios> Desacoplar os diversos participantes;> Eliminar relacionamentos N-to-N;> Centralizar o controle;> Facilitar inclusão de novos

participantes.


Mediator

Problema

Solução


Adapter

> Converter a interface de uma classe em outra interface esperada pelo cliente. Atuar como um intermediário entre duas classes, convertendo a interface de uma para que a mesma possa ser utilizada pela outra.

> Benefícios> Permitir dois objetos incompatíveis se

comunicar e interagir;> Elevar a reusabilidade de sistemas

antigos.


Adapter


Proxy

> Prover um objeto substituto para interceptar e controlar o acesso a um outro objeto.

> Benefícios> Esconder complexidades

relacionadas com o acesso ao objeto destino (acesso remoto);

> Transparência para o cliente;> Permitir maior eficiência com

caching no cliente


Proxy

> Exemplo> Stubs e Skeletons do Java RMI.


Flyweight

> Utilizar o mecanismo de compartilhamento de instâncias para suportar uma alto número de objetos na aplicação de maneira eficiente.

> Benefícios> Reduzir número de objetos a

serem tratados pela aplicação;> Reduzir utilização de memória;


Flyweight

Problema Solução


Flyweight

Exemplo Implementação

Usando Caching


Template Method

> Definir o esqueleto de um algoritmo dentro de uma operação em uma classe, deixando alguns passos a serem preenchidos pelas subclasses.


Template Method


Core J2EE Patterns

> Surgiu com a publicação do livro Core J2EE Patterns em 2001;

> Descreve um catálogo de 25 padrões específicos para plataforma Java EE;

> Produto de anos de experiência aplicados em consultoria em projetos Java EE, documentados por consultores da Sun Microsystems.

> Atualmente este livro encontra-se publicado em segunda edição, com alguns “novos” design patterns;


Core J2EE Patterns

> Os padrões encontram-se sub-divididos em três categorias:> Apresentação> Negócio> Integração


Intercepting Filter

> Permitir o pré e/ou pós processamento de uma requisição para um determinado componente, possibilitando a facilidade na configuração de ativação e desativação deste processamento.

> Benefícios> Centralizar controle;> Promover a reusabilidade;> Fornecer flexibilidade através de

configurações declarativas;


Intercepting Filter

Problema ->

<- Solução


Front Controller

> Centralizar o processamento de requisições em uma único e centralizado componente. Redirecionar o processamento após sua finalização, para a view respectiva.

> Benefícios> Controle centralizado;> Melhorar gerenciamento de segurança;> Promover reuso;


Front Controller

Problema ->

<- Solução


View Helper

> Separar do código as responsabilidades de formatação da interface do usuário, do processamento de dados necessário à construção da view.


View Helper

Problema Solução


Composite View

> Componentizar a view para a partir de views menores dividir as responsabilidades, simplificar a construção da interface e promover o reuso.


Composite View

Problema ->

<- Solução


Business Delegate

> Esconder dos clientes detalhes acerca da camada de negócios, fornecendo uma interface de serviços semelhantes aos serviços de negócio.

> Benefícios> Reduzir acoplamento;> Traduzir exceções dos serviços de negócio;> Expor interfaces mais simples;> Poder melhorar performance utilizando

estratégias de cache;> Implementar recuperação à falhas;> Ocultar o fato dos objetos de negócio estarem

remotos.


Business Delegate

Problema ->

<- Solução


Service Locator

> Esconder dos clientes a necessidade do conhecimento dos serviços de localização (JNDI) e da lógica necessária para utilização do mesmo, fornecendo uma interface simplificada para recuperar os componentes remotos.


Service Locator

Problema Solução

Client InitialContext

Create

Lookup

Create

EJB

Invoke Business Method

ServiceLocator InitialContext

Create

Lookup

Create

EJB

Invoke Business Method

Client

Obtain Business Service


Session Facade

> Simplificar a interface do cliente dos componentes de negócio e controlar o acesso e a lógica de negócio entre os componentes existentes.

> Benefícios> Introduzir uma camada

controladora;> Expor uma interface uniforme;> Reduzir o acoplamento do cliente;> Melhorar a performance> Centralizar o controle de segurança

e transações;> Reduzir a interface visível para o

cliente.


Session Facade

Problema Solução

Client Components

Subsystem Components

Client Components

Subsystem Components

Facade


Business Object

> Separar dados de negócio da lógica usando um modelo de objetos. Abstrair os dados de negócio da aplicação, representando uma entidade.


Business Object

Problema ->

<- Solução


Transfer Object

> Reduzir a quantidade de requisições necessárias para recuperar um objeto. Encapsular um subconjunto de dados a ser utilizado pelo cliente, afim de retorná-los em somente uma requisição remota.


Transfer Object

Problema ->

<- Solução


Data Access Object

> Abstrair e encapsular todo o acesso a uma fonte de dados, separando-a do código de negócio e visualização da aplicação.


Data Access Object

Problema ->

<- Solução


Service Activator

> Receber requisições e mensagens assíncronas do cliente. Localizar e chamar os métodos de negócio para atender as requisições de forma assíncrona.


Service Activator

Problema ->

<- Solução


Domain Store

> Oferecer um mecanismo transparente para persistência dos objetos de negócio. Abstrair o repositório de dados do cliente, afim de fornecer um mecanismo de persistência automático.

> Benefícios> Separar modelo de objetos de

negócio da lógica de persistência;

> Melhorar testabilidade da camada de persistência;


Domain Store

Problema ->

<- Solução


Outros Design Patterns...


Conclusões

> Será que alguns padrões de projetos morreram com a evolução das novas tecnologias?

> Devo realmente utilizar padrões de projetos na minha aplicação?

> Qual será o futuro dos padrões de projetos? Terão eles um fim?


Perguntas e Respostas

?

design patterns quais padrões ainda sobrevivem com as novas tecnologias?

Documents