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

Apresentação em tema: "Design Patterns Patrícia Mateus nº3343 Carla Guerreiro nº3157"— Transcrição da apresentação:

1 Design Patterns Patrícia Mateus nº3343 Carla Guerreiro nº3157
Escola 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

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: Problema: Solução: Consequências:
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 OMT – Object Modeling Technique)

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. Devemos escolher o DP cujo objectivo seja relevante para a solução do problema, estudando o inter-relacionamento entre patterns com objectivos semelhantes. Verificar quais as causas do redesenho e ver quais os patterns que os evitam. Considerar também o que poderá ser preciso mudar sem ter que redesenhar o sistema

10 Classificação Propósito Âmbito
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. aqueles que focam as relações entre classes.

13 Chain of Responsibility
Classificação Propósito Criação Estrutural Comportamental Âmbito Classe Factory Adapter Interpreter Template Objecto Abstract Factory Builder Prototype Singleton Bridge Composite Decorator Facade Proxy Chain of Responsibility Command Iterator Mediator Memento Flyweight Observer State Strategy Visitor Figura1 – As 23 categorias organizadas segundo a sua classificação

14 Exemplo (Iterator) Nome do Pattern e Classificação: Propósito:
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. 2- sequencialmente, sem exposição de estruturas internas.

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 Representação gráfica das classes
Exemplo (Iterator) Estrutura: Cliente Representação gráfica das classes Retirado de

17 Exemplo (Iterator) Participantes:
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. Exemplos – sistema de repositório em que poderiamos inserir, remover, actualizar, obter dados dos cliente. Ou seja, deveríamos criar um objecto (Iterator) que seria utilizado para acedermos a todos os clientes do repositório de forma sequencial.

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

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 A ideia de programação em frameworks era popular e com o seu desenvolvimento os design Patterns começaram a emergir.

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. Uma framework pode ser gerada para representar um editor gráfico para diferentes domínios, tais como desenho, composição musical e CAD mecânico ; os design patterns são menos especializados do que o framework, pois o framework tem sempre domínio de aplicação específico;

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: