Design Patterns (Padrões de Projeto)

1. Design Patterns (Padrões de Projeto) Jobson Ronan {jrjs@cin.ufpe.br}

2. Objetivos • Explicar: • O que é um padrão de projeto • Alguns padrões que já foram identificados no desenvolvimento de software • Como aplicar padrões de projeto durante o desenvolvimento de software • Os benefícios e dificuldades que podem surgir quando usamos padrões de projeto

3. Motivação • Projetar software OO reusável e de boa qualidade é difícil • Mistura de específico + genérico • Impossível acertar da primeira vez • Projetistas experientes usam soluções com as quais já trabalharam no passado • Padrões de projeto • Uso sistemático de: • nomes, • explicações, • e avaliações • Durante a última década, uma “comunidade de padrões” foi desenvolvida

4. Definições • “Cada padrão descreve um problema que ocorre freqüentemente em seu ambiente, e então descreve o núcleo de uma solução para o problema, de maneira que você possa usar esta solução um milhão de vezes, sem fazê-la do mesmo jeito duas vezes.” Christopher Alexander (Arquiteto e Urbanista), 1977 • “Um padrão é a abstração de uma forma concreta que ocorre muitas vezes em contextos não arbitrários específicos.” Riehle and Zullighoven, 1996 • “Resolve um problema. É um conceito provado. A solução não é óbvia. Descreve um relacionamento. Os padrões têm um componente humano significativo.” Coplien 1996.

5. Características • Algo comprovado que captura e comunica os conhecimentos das melhores práticas • Descoberto, não inventado • Soluções Sucintas e de Fácil Aplicação • Capturam, de forma sucinta e facilmente aplicável, soluções de projeto de programas de computador que foram desenvolvidas e evoluíram com o passar do tempo • Soluções Exaustivamente Refinadas • Resultados de um longo processo de projeto, re-projeto, teste e reflexão sobre o que torna um sistema mais flexível, reusável, modular e compreensível • Soluções Compartilhadas • Construídas em grupo • Através do uso de um vocabulário comum

6. Outros Tipos de Padrões • Padrões de Análise: • Descrevem grupos de conceitos que representam construções comuns na modelagem do domínio. Estes padrões podem ser aplicáveis em um domínio ou em muitos • Padrões de Arquitetura: • Descrevem a estrutura e o relacionamento dos componentes de um sistema de software • Padrões de Processo

7. Catálogos e Linguagens de Padrões • Um catálogo de padrões é um grupo de padrões que estão relacionados de uma certa forma e podem ser usados juntos ou independentemente • Os padrões numa linguagem de padrões estão relacionados, e trabalham juntos para solucionar problemas num domínio específico • um conjunto de padrões que trabalham juntos para solucionar um grande problema

8. Princípios Presentes nos Padrões • Abstração • Encapsulamento • Proteção de informação • Modularização • Separação de conteúdos • Acoplamento e coesão • Suficiência, completude e primitividade • Separação entre interface e implementação • Único ponto de referência • Dividir para conquistar

9. Anti-Padrões • São uma maneira de documentar soluções recorrentes que não tiveram sucesso • Podem também incluir soluções re-trabalhadas que sejam efetivas • “Gambiarras Clássicas”

10. Elementos para Documentação • Nome: • Resume em uma ou duas palavras: o problema, as soluções e conseqüências do uso do padrão. • Deve ser facilmente lembrado, reflete o conteúdo do padrão. • Problema: • Descreve quando aplicar o padrão. Explica o problema e seu contexto. Sintomas e condições. • Solução: • Elementos que constituem o design, seus relacionamentos, responsabilidades e colaboradores. • Conseqüências: • Resultados e compromissos decorrentes da aplicação do padrão. • Impactos sobre a flexibilidade, extensibilidade,portabilidade ou desempenho do sistema.

11. Outros Elementos • Um exemplo de uso • A razão que justifica a solução escolhida • Padrões relacionados • Uso conhecido do padrão • Lista de outros nomes para o padrão • Amostra de código em uma linguagem de programação

12. Tipos de Padrões de Projeto • Padrões de Projeto foram introduzidos para a comunidade OO através de • Gamma E., et al, Design Patterns, Addison-Wesley, 1994 • Eles categorizaram (23) padrões em três tipos: • Estruturais (7) • Criacionais (5) • Comportamentais (11) • divididos em 2 escopos: • Classe • Objeto

13. Escopo • Classe • Relacionamentos entre classes e suas subclasses • Não é preciso executar nenhum código para determinar ouso dos padrões • Estáticos: fixos em tempo de compilação • Objeto • Confia em ponteiros de objetos • Dinâmicos: relacionamentos entre objetos podem ser alterados em tempo de execução

14. Detalhamento dos Tipos de Padrões • Estruturais • Tratam de compor classes e objetos para formar estruturas grandes e complexas • Associados à maneira como classes e objetos sãoorganizados estruturalmente • Oferecem formas efetivas para usar conceitos OO comoherança, agregação e composição • Focam na abstração da estrutura

15. Detalhamento dos Tipos de Padrões • Criacionais • Associados ao processo de criação de objetos • Tornam um sistema independente de como seus objetos são criados, compostos e representados • Comportamentais • Tratam de algoritmos e como atribuir responsabilidades entre objetos • Associados à maneira que objetos e classes distribuem suas responsabilidades para realizar uma tarefa • Focam na abstração do comportamento

16. Alguns Exemplos • Padrão Composite (estrutural) • Padrão Singleton (criacional) • Padrão State (comportamental)

17. Padrão Estrutural: Composite • Nome: • Composite • Problema: • Se existe um requisito para representar hierarquias todo-parte, então ambos objetos (todo e parte) oferecem a mesma interface para objetos cliente. • Contexto: • Numa aplicação tanto o objeto que contém quanto o que é componente devem oferecer o mesmo comportamento. • Objetos cliente devem ser capazes de tratar objetos compostos ou componentes do mesmo jeito.

18. Padrão Estrutural: Composite • Forças: • O requisito que os objetos, tanto composto como componente, ofereçam a mesma interface, sugere que elespertençam à mesma hierarquia de herança. • Isto permite que operações sejam herdadas e redefinidas com a mesma assinatura (polimorfismo). • A necessidade de representar hierarquias todo-parte indica a necessidade de uma estrutura de agregação

19. Padrão Estrutural: Composite • Solução : Combinar hierarquias de herança e agregação.

20. Padrão Estrutural: Composite • Solução: • Ambas subclasses, Leaf e Composite, têm uma operação redefinida usando polimorfismo anOperation(). • Na classe Composite esta operação redefinida invoca a operação relevante a partir de seus componentes usando um loop. • A subclasse Composite também tem operações adicionais para gerenciar a hierarquia de agregação, então os componentes podem ser adicionados ou removidos.

21. Exemplo: Campanhas de Midia

22. Exemplo: Sistema de Arquivos

23. Padrão de Criação: Singleton • Nome: • Singleton • Problema: • Como pode ser construída uma classe que só pode ter uma única instância e que pode ser acessada globalmente dentro da aplicação? • Contexto: • Em algumas aplicações, uma classe deve ter exatamente uma instância.

24. Padrão de Criação: Singleton • Forças: • Uma abordagem para tornar um objeto acessível globalmente é colocá-lo como uma variável global. • Outra abordagem é não criar uma instância de objeto em nenhum lugar, mas usar operações e atributos de classe (chamados ‘static’ em C++ e Java).

25. Padrão de Criação: Singleton • Solução: • Criar uma classe com uma operação de classe (ou estática, ex: Java, C++) getInstance(), que: • Quando a classe é acessada pela primeira vez, a instância do objeto é criada e retornada para o cliente. • Nos acessos subseqüentes a getInstance() nenhuma instância adicional é criada, mas a identidade do objeto existente é retornada.

26. Padrão de Criação: Singleton • Vantagens: • Oferece acesso controlado à única instância do objeto, pois a classe Singleton encapsula a instância. • A classe Singleton pode ter subclasses. Pode-se determinar que subclasses são instanciadas quando a classe Singleton é acessada pela primeira vez. • Uma variação do padrão pode ser usada para criar um número específico de instâncias, se for requerido.

27. Padrão Singleton: Um Exemplo de Uso • O sistema de gerenciamento de campanhas de uma empresa precisa guardar informações a respeito da empresa. • Estas informações só devem ser guardadas em um único lugar dentro da aplicação, mas serão usadas por diferentes objetos. • Quando um objeto cliente precisa acessar o objeto Company, pode enviar a mensagem getCompanyInstance() e receber o identificador do objeto na resposta. • O objeto cliente pode então enviar uma mensagem getCompanydetails() para o objeto Company

28. Padrão Singleton: Exemplo

29. Padrão Comportamental: State • Nome: • State • Problema: • Um objeto exibe um comportamento diferente quando seu estado interno muda, fazendo o objeto parecer ter mudado a classe em tempo de execução. • Contexto: • Ema algumas aplicações um objeto pode ter o comportamento complexo que seja dependente do seu estado. A resposta para uma mensagem

30. Padrão Comportamental: State • Forças: • O objeto tem comportamento complexo que deve ser dividido em elementos menos complexos. Uma ou mais operações têm comportamento que variam de acordo com o estado do objeto. • Tipicamente a operação teria muitas sentenças condicionais dependentes do estado. • Uma abordagem é ter operações públicas diferentes para cada estado, mas objetos cliente precisariam saber o estado do objeto para poderem chamar a operação adequada

31. Padrão Comportamental: State • Solução: • Separar o estado dependente do comportamento do objeto original e alocar este comportamento para um série deoutros objetos, um para cada estado. • Estes objetos estado têm apenas responsabilidade relacionadas ao comportamento do respectivo estado.

32. Padrão Comportamental: State

33. Participantes do Padrão State • Context • define a interface de interesse para clientes. • Mantém uma instância de uma subclasse ConcreteState que define o estado corrente • State • define uma interface para encapsulamento do comportamento associado com um estado específico do Contexto • Subclasses ConcreteState • cada subclasse implementa um comportamento associadocom um estado do Contexto

34. Padrão Comportamental: State • Vantagens: • O comportamento do estado é localizado e o comportamento para diferentes sub-estados é separado. • Isto facilita qualquer modificação do comportamento do estado, em particular a adição de estados extra. • Transições de estado são explícitas. O objeto estado, queestá ativo, indica o estado atual do objeto Contexto.

35. Padrão Comportamental: State • Desvantagens: • O objeto Estado pode ser criado ou removido quando o objeto Context muda o estado, introduzindo assim um overhead no processamento. • O uso do padrão State introduz pelo menos uma mensagem extra, a mensagem da classe Context para classe State, adicionando assim mais overhead no processamento.

36. Padrão State: Um Sistema de Biblioteca • As subclasses concretas definem o método de acordo com o estado que elas representam

37. Questões Relativas ao Uso de Padrões • Existe algum padrão que trata um problema similar? • O contexto do padrão é consistente com o problema real? • As conseqüências do uso de padrão são aceitáveis? • O padrão tem uma solução alternativa que pode ser mais aceitável? • Existe uma solução mais simples? • Existem algumas restrições que sejam impostas pelo ambiente de software que está sendo usado?

38. Problemas com o Catálogo de Padrões • Armazenamento, busca e manutenção da documentação de padrões • Padrões colecionados num catálogo precisam ser agrupados • Projetistas descobrindo novos padrões precisam considerar onde o seu novo padrão se encaixa no catálogo • Publicação de padrões disponíveis • Todos os usuários precisam ser atualizados sobre o conteúdo do catálogo

39. Perigos do Uso de Padrões • O uso de padrões de uma maneira descontrolada pode originar projetos sobre-carregados. • Desenvolvedores: • Precisam de tempo para entender os catálogos de padrões relevantes • Precisam de fácil acesso a catálogos relevantes • Precisam ser treinados no uso de padrões

40. Padrões de Projeto para Arquitetura em Camadas • Padrão Façade • Padrão Persistent Data Collections (PDC)

41. Padrão Façade • Intenção • Prover uma interface unificada para o conjunto de interfaces de um subsistema. Define uma interface de alto nível que faz um subsistema mais fácil de usar. • Motivação • Estruturar um sistema em subsistemas contribui para reduzir sua complexidade. A dependência entre subsistemas pode ser minimizada através do uso de um objeto Fachada, o qual provê uma interface única e uniforme para as diversas funcionalidades de um subsistema.

42. Padrão Façade: Estrutura e Participantes

43. Padrão Façade: Aplicabilidade • Use o Padrão Façade quando: • Você quer prover uma interface simplificada para um subsistema complexo. Um Façade pode prover uma visão simples do subsistema, suficiente para a maioria dos clientes • Existem muitas dependências entre clientes e classes da implementação. O Façade reduz esta dependência e promove independência e portabilidade • Você quer criar sistemas em camadas. Um Façade provê o ponto de entrada para cada camada (nível) do subsistema.

44. Padrão Façade: Conseqüências • Promove acoplamento fraco entre o subsistema e seus clientes • No entanto, não evita que aplicações possam acessar diretamente as subclasses do sistema, se assim o desejarem.

45. Padrão Persistent Data Collections (PDC) • Nome: • PDC • Problema: • Como melhorar os níveis de manutenção e reuso quando usando mecanismos de persistência em aplicações orientadas a objeto? • Contexto: • Durante o desenvolvimento de aplicações orientadas a objeto que utilizam mecanismos de persistência, através de APIs (Application Programming Interfaces) específicas, é possível que o código gerado misture a lógica da aplicação com os mecanismos de persistência, dificultando assim a manutenção e o reuso.

46. Padrão PDC • Forças: • Desenvolvedores devem poder endereçar os aspectos de negócio de uma organização independente das operações de persistência. • O mecanismos de persistência podem mudar durante o período de vida da aplicação. • Classes de negócio podem ser usadas por outras aplicações. • O mecanismo de persistência deve lidar de forma eficiente com a habilitação de conexões com o banco de dados e com o gerenciamento de transações. • A performance do sistema não deve ser afetada.

47. Padrão PDC • Solução: • Separar as classes de análise em duas categorias: • Classes descrevendo os objetos de negócio. • Classes para a manipulação e armazenamento de dados, com código específico para o tratamento de persistência.

48. Padrão PDC

49. Design Patterns (Padrões de Projeto) Jobson Ronan {jrjs@cin.ufpe.br}