Design Patterns Apresentação elaborada por: Carla Guerreiro nº3157 Patrícia Mateus nº3343 Beja, 14 de Dezembro de 2005 cola Superior de Tecnologia e Gestão Instituto Politécnico de Beja
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