Design Patterns

Apresentação elaborada por:

Carla Guerreiro nº3157 Patrícia Mateus nº3343

Beja, 14 de Dezembro de 2005

Escola Superior de Tecnologia e Gestão Instituto Politécnico de Beja

Conteúdos• Introdução;• História;• O que são Design Patterns;• Como são constituídos;• Como descrever e escolher um Design Pattern;• Classificação;• Exemplo (Iterator);• Vantagens e Desvantagens;• Design Patterns VS Frameworks ;

Introdução

• Design Patterns representam, geralmente, uma solução a um problema comum no desenho de software.

• Desenvolver software orientado a objectos é complicado mas desenvolver software reutilizável orientado a objectos ainda é mais complicado.

• Design Patterns podem acelerar o desenvolvimento ao providenciar paradigmas de desenvolvimento já testados e provados.

História• O conceito patterns foi originário na indústria da construção. Arquitectos

aperceberam-se que precisavam de partilhar ideias sobre técnicas de design.

• “Cada pattern descreve um problema que ocorre por diversas vezes no nosso ambiente, e então descreve o núcleo da solução àquele problema de tal forma que a solução pode ser utilizada milhares de vezes” – Christopher Alexander (Arquitecto).

• Os design patterns deram o salto da arquitectura para os sistemas de computadores nos anos 80.

• A filosofia object-oriented (OO) estava a ganhar popularidade e os design patterns eram uma forma de educar os seguidores OO da melhor forma.

O que são design patterns• Consistem numa documentação de soluções genéricas e reutilizáveis,

aplicáveis em problemas recorrentes.

• descreve o problema, a sua solução, quando esta deve ser aplicada e quais as suas consequências. Enumera também algumas dicas e exemplos de implementação.

• são descrições de objectos e classes interrelacionados que são adaptados para resolver um problema de design num contexto particular.

Como são constituídos Nome:

descreve sucintamente o problema; Problema:

descreve quando se deve aplicar; Solução:

descreve os elementos que constituem o design (as suas relações, responsabilidades e colaborações);

Consequências: - resultados e transacções da aplicação do pattern; - engloba o impacto na flexibilidade, extensibilidade ou portabilidade do sistema;

Como descrever um Design Pattern 1.1. Nome do padrão e sua classificação:Nome do padrão e sua classificação:

o nome deve ser identificativo e a sua classificação é feita segundo critérios explicados mais à frente.

2.2. Objectivo:Objectivo: descrição do que o pattern faz, qual o objectivo a atingir e para que problemas está direccionado.

3.3. Motivação:Motivação: um cenário que ilustra o problema e de que forma as classes e estruturas de objectos envolvidas o resolvem.

4.4. Aplicabilidade:Aplicabilidade: quais as situações em que o pattern pode ser aplicado e como podemos reconhecer essas situações.

5.5. Estrutura:Estrutura:- representação gráfica das classes usando OMT. - usados diagramas de interacção

Como descrever um Design Pattern6.6. Participantes:Participantes: responsabilidades das classes e objectos participantes.7.7. Colaborações:Colaborações: como os participantes colaboram para levar a cabo as

responsabilidades.8.8. Consequências:Consequências: quais os prós e os contras e os resultados inerentes ao

uso do pattern. Que aspectos do sistema podem variar independentemente.

9.9. Implementação:Implementação: quais as dicas e técnicas a considerar nesta fase.10.10. Amostras de código:Amostras de código: fragmentos de código que ilustram uma possível

forma de implementação.11.11. Exemplos de utilização:Exemplos de utilização: exemplos de patterns encontrados em sistemas12.12. Padrões relacionados:Padrões relacionados: patterns relacionados, quais as principais

diferenças e com que patterns podem ser utilizados.

Como escolher um Design Pattern• Considerar como o design pattern resolve determinado problema.• Procurar pelo pattern cujo objectivo seja relevante para a solução do

problema.• Estude o inter-relacionamento entre patterns graficamente.• Estudo de patterns com objectivos semelhantes.• Examine a causa do redesenho: verifique se o problema envolve

alguma dessas causas e verifique quais os padrões que as evitam.• Considere o que deve ser variável no seu design. Neste caso é

considerado o que forçará uma mudança no design, ou seja, considere o que poderá precisar de mudar sem ter que redesenhar o sistema.

ClassificaçãoOs design patterns podem ser classificados segundo dois critérios:

Propósito Criação Estrutural Comportamental

Âmbito Class Pattern Object Pattern

Classificação: propósito• Patterns de criação:

criam objectos por si, sem que tenha que instanciá-los directamente; programa com mais flexibilidade em decidir quais os objectos que

devem ser criados para determinado caso. podem ser competidores ou complementares.

• Patterns estruturais: ajudam a compor grupos de objectos em amplas estruturas, tais como

interfaces de utilizador complexas.

• Patterns comportamentais: auxiliam na definição da comunicação entre objectos no sistema e

como o seu fluxo é controlado num programa complexo.

Classificação: âmbito• Classe:

patterns aplicados a classes lidam com relações entre classes e as suas subclasses;

as relações são estabelecidas através da herança de classes; são estáticas.

• Objecto: patterns aplicados a objectos lidam com as relações dos objectos; podem ser modificados durante a execução; são mais dinâmicos.

Classificação

Propósito

Criação Estrutural Comportamental

Âmbito

Classe Factory Adapter InterpreterTemplate

Objecto Abstract FactoryBuilder

PrototypeSingleton

AdapterBridge

Composite Decorator

FacadeProxy

Chain of ResponsibilityCommand

IteratorMediatorMementoFlyweightObserver

StateStrategyVisitor

Figura1 – As 23 categorias organizadas segundo a sua classificação

Exemplo (Iterator)• Nome do Pattern e Classificação:

Iterator – Comportamental (Object Pattern)• Propósito:

Providência um modo de acesso a elementos de um agregado de objectos.

• Motivação: Um objecto que possua agregações deve permitir que os seus elementos sejam acedidos sem que a sua estrutura interna seja

exposta.

Exemplo (Iterator)

• Aplicação:

aceder ao conteúdo de objecto agregados sem expor a sua representação interna;

suportar mais de uma maneira de percorrer a lista; Providenciar uma interface única para percorrer diferentes

estruturas agregadas;

Exemplo (Iterator)• Estrutura:

Iterator

First()Next()IsDone()CurrentItem()

Aggregate

CreateIterator()

<<Interface>>

ConcreteAggregate

CreateIterator()

ConcreteIterator

return new ConcreteIterator (this)

Retirado de www.inf.ucp.br/profs/tavares/2002_01/aulaDP-1.ppt

Cliente

Representação gráfica das classes

Exemplo (Iterator)• Participantes:

• Iterator• Define um interface para aceder e percorrer os elementos;

• ConcreteIterator• Implementa a interface do Iterator;• Mantém a informação sobre o elemento percorrido;

• Aggregate• Define um interface para a criação do objeto Iterator;

• ConcreteAggregate• Implementa o método da interface que retorna uma instância do

ConcreteIterator.• Colaborações: ConcreteIterator mantém a referência do objecto que está a ser

percorrido, podendo calcular qual o elemento seguinte.

Exemplo (Iterator)• Consequências:

• Suporta alterações na forma como é percorrida a lista;• Simplifica a interface Aggregate; • Podem ser feitos vários percursos, já que o seu estado é

armazenado em cada Iterator.• Patterns Relacionados:

• Composite: Estruturas recursivas;• Factory Method;• Memento.

• Exemplos de Utilização: sistema de repositório de clientes.

Design PatternsVANTAGENS:• Reutilização de soluções;• Estabelecimento de terminologia

comum;• perspectiva de alto nível do

problema (abstracção) e do processo de design;

• Ilustra os princípios básicos da orientação a objectos;

• Facilitar modificações;

DESVANTAGENS:• Os programadores são tentados a

recorrer ao uso dos patterns mesmo quando não é apropriado a sua utilização;

• Pode limitar a criatividade;• Pode aumentar a complexidade

de design dificultando a manutenção do código;

Frameworks

• Técnica de reutilização orientada a objectos que compreende tanto design como código, com uma representação física em termos de classes, métodos e objectos.

• Objectivo:• Diminuir a quantidade de código necessária para implementar

aplicações similares

Design Patterns VS Frameworks• os design patterns são mais abstractos e gerais;• Design Patterns não podem ser directamente

implementados num determinado ambiente de software;• um framework pode conter vários design patterns; • Design Patterns permitem a reutilização da arquitectura;• Frameworks permitem a reutilização do código.

Juntos, permitem a melhoria da qualidade do software e reduzem o tempo de desenvolvimento.

Conclusão• Design Patterns não são uma solução para todos os problemas de

desenvolvimento de software, mas pode se tornar numa ferramenta valiosa.

• Não existem soluções nem respostas perfeitas, por isso é necessário bom senso na utilização de design patterns.

• Os design patterns descrevem a forma como os objectos comunicam sem que se emaranhem nos diferentes modelos e métodos. Conservar esta separação tem sido um dos principais objectivos de uma correcta programação orientada a objectos.

Referências Bibliográficas Livros:

o E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design Patterns:

Elements of Reusable Object-Oriented Software. Addison-Wesley, 1995.

o A. Shalloway, J.R. Trott, Design Patterns Explained

Formato electrónico:http://dsc.upe.br/~scbs/unicap/poo/Iterator.htmlhttp://jacques.dsc.ufcg.edu.br/cursos/map/html/map2.htmhttp://www.developer.com/design/article.php/3309461http://coronet.iicm.edu/sa/scripts/lesson12.htm#_Toc6032417