O documento explica o que são padrões de projeto, alguns padrões identificados e como aplicá-los no desenvolvimento de software. Apresenta os benefícios e desafios do uso de padrões, como facilitar a reutilização de código e a manutenção do software.

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}