Design Patterns (Padrões de Projeto)

Apresentação em tema: "Design Patterns (Padrões de Projeto)"— Transcrição da apresentação:

1 Design Patterns (Padrões de Projeto)
Jobson Ronan

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 Objeto 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 Motivaçã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: A performance do sistema não deve ser afetada.
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