Design Patterns

1. Design Patterns Escola Superior de Tecnologia e Gestão Instituto Politécnico de Beja Apresentação elaborada por: Carla Guerreiro nº3157 Patrícia Mateus nº3343 Beja, 14 de Dezembro de 2005

2. 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 ;

3. 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.

4. 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.

5. 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.

6. 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;

7. Como descrever um Design Pattern • 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. • Objectivo: descrição do que o pattern faz, qual o objectivo a atingir e para que problemas está direccionado. • Motivação: um cenário que ilustra o problema e de que forma as classes e estruturas de objectos envolvidas o resolvem. • Aplicabilidade: quais as situações em que o pattern pode ser aplicado e como podemos reconhecer essas situações. • Estrutura: - representação gráfica das classes usando OMT. - usados diagramas de interacção

8. Como descrever um Design Pattern • Participantes: responsabilidades das classes e objectos participantes. • Colaborações: como os participantes colaboram para levar a cabo as responsabilidades. • Consequências: quais os prós e os contras e os resultados inerentes ao uso do pattern. Que aspectos do sistema podem variar independentemente. • Implementação: quais as dicas e técnicas a considerar nesta fase. • Amostras de código: fragmentos de código que ilustram uma possível forma de implementação. • Exemplos de utilização: exemplos de patterns encontrados em sistemas • Padrões relacionados:patterns relacionados, quais as principais diferenças e com que patterns podem ser utilizados.

9. 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.

10. Classificação Os design patterns podem ser classificados segundo dois critérios: • Propósito • Criação • Estrutural • Comportamental • Âmbito • Class Pattern • Object Pattern

11. 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.

12. 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.

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

14. 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.

15. 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;

16. Exemplo (Iterator) • Estrutura: Cliente Representação gráfica das classes Retirado de www.inf.ucp.br/profs/tavares/2002_01/aulaDP-1.ppt

17. 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.

18. 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.

19. VANTAGENS: 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; Design Patterns

20. 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

21. 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.

22. 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.

23. Referências Bibliográficas • Livros: • E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, 1995. • A. Shalloway, J.R. Trott, Design Patterns Explained • Formato electrónico: http://dsc.upe.br/~scbs/unicap/poo/Iterator.html http://jacques.dsc.ufcg.edu.br/cursos/map/html/map2.htm http://www.developer.com/design/article.php/3309461 http://coronet.iicm.edu/sa/scripts/lesson12.htm#_Toc6032417