1) O documento discute padrões de projetos orientados a objetos, especificamente padrões estruturais e comportamentais. 2) Padrões estruturais como Decorator e Facade tratam de como classes e objetos são compostos para formar estruturas maiores, enquanto padrões comportamentais como Observer e Strategy tratam de algoritmos e responsabilidades entre objetos. 3) Exemplos e diagramas são fornecidos para ilustrar como cada padrão é aplicado na prática.

1. padrões de projetos orientados à objetos
Padrões de Projetos Estruturais e Comportamentais
Gustavo Carvalho Souza
4 Agosto 2017
Seminário Apresentado à disciplina de Linguagens de Programação
Universidade Federal de Lavras - UFLA
Programa de Pós Graduação em Ciência da Computação

2. sumário
1. Padrões Estruturais
1.1 Visão Geral
1.2 Tipos
• Decorator
• Façade
1.3 Observação sobre Padrões Estruturais
2. Padrões Comportamentais
2.1 Visão Geral
2.2 Tipos
• Observer
• Strategy
2.3 Observação sobre Padrões Comportamentais
3. Conclusão
2

3. padrões de projetos estruturais

4. visão geral
1. Contexto
• Preocupam-se com a forma como classes e objetos são
compostos para formar estruturas maiores.
• Ao contrário dos padrões de projetos criacionais, que são
principalmente maneiras diferentes de cumprir o mesmo
propósito fundamental, cada padrão estrutural tem um propósito
diferente.
4

5. visão geral
2. Padrões Estruturais de classe
• Os padrões estruturais de classes utilizam a herança para compor
interfaces ou implementações.
5

6. visão geral
3. Padrões Estruturais de Objetos
• Os padrões estruturais de objetos descrevem maneiras de compor
objetos para obter novas funcionalidades, em lugar de compor
interfaces ou implementações.
6

7. decorator

8. decorator
• Intenção: Agregar responsabilidades adicionais a um objeto,
fornecendo uma alternativa flexível ao uso de subclasses para
extensão de funcionalidades.
• Motivação: Necessidade de acrescentar responsabilidades a
objetos individuais, e não a toda classe.
• Cenário: um toolkit para construção de interfaces gráficas de
usuário deveria permitir a adição de propriedades, como
bordas, ou comportamentos, como rolamento, para qualquer
componente da interface do usuário.
• Utilizar Herança é a melhor solução?
• Embutir o componente em outro objeto que acrescente a borda é
uma solução mais flexível?
8

9. decorator
• Quando embutirmos o componente em outro objeto que possui
borda teremos:
• O objeto que envolve o primeiro é chamado de decorator.
• Este decorator segue a interface do componente que o decora.
• O decorator repassa solicitações para o componente, podendo
executar ações adicionais (tais como desenhar uma borda) antes
ou depois do repasse.
• A transparência permite encaixar decoradores recursivamente,
desta forma permitindo um número ilimitado de
responsabilidades adicionais.
• Aplicação: Suponha que tenhamos um objeto TextView que
exibe texto numa janela.
• TextView não tem barras de rolamento nem borda preta espessa
ao redor do objeto porque nem sempre a necessitamos;
9

10. decorator
• Pode-se acrescentar barras de rolamento no TextView utilizando
um ScrollDecorator.
• Pode-se acrescentar bordas pretas no TextView usando um
objeto BorderDecorator.
• Isto é feito compondo os decoradores com TextView.
Figure 1: Composição dos decoradores com o TextView. (Gamma et al.,
2006)
10

11. decorator
• Diagrama de Objetos
Figure 2: Composição de um objeto TextView com objetos
BorderDecorator e ScrollDecorator para produzir uma visão do texto
cercada por bordas e rolável.
11

12. decorator
• Diagrama de Classes
Figure 3: Diagrama de classes para a aplicação de composição de
decoradores com o TextView. (Gamma et al., 2006)
12

13. decorator
• Estrutura e Participantes
Figure 4: Estrutura e participantes da composição de
decorators.(Gamma et al., 2006)
13

14. decorator
• Aplicabilidade
Quando usar Decorator?
• para acrescentar responsabilidades a objetos individuais de
forma dinâmica sem afetar outros objetos;
• para responsabilidades que podem ser removidas;
• quando a extensão através do uso de subclasses não é prática.
• Consequências
Possui pelo menos dois benefícios e duas deficiências.
1. Maior flexibilidade do que a herança estática;
2. Evita classes sobrecarregadas de características na parte superior
da hierarquia;
3. Um decorador e o seu componente não são idênticos;
4. Grande quantidade de pequenos objetos.
14

15. decorator
• Implementação
15

16. façade

17. façade
• Intenção: Fornecer uma interface unificada para um conjunto de
interfaces em um subsistema. Façade define uma interface de
nível mais alto que torna o subsistema mais fácil de ser usado.
• Motivação: Estruturar um sistema em subsistemas ajuda a
reduzir a complexidade. Um objeto façade (fachada) fornece
uma interface única e simplificada para os recursos e
facilidades mais gerais de um subsistema.
Figure 5: Apresentação de sistemas sendo estruturados em
subsistemas. (Gamma et al., 2006)
17

18. façade
• Aplicação: Um ambiente de programação que fornece acesso às
aplicações para o seu subsistema compilador.
• Esse subsistema contém classes, tais como Scanner, Parser,
ProgramNode, BytecodeStream e ProgramNodeBuilder, que
implementam o compilador.
• A maioria dos clientes de um compilador apenas querem compilar
seu código.
• Para fornecer uma interface de nível mais alto o subsistema
compilador também inclui uma classe Compiler.
• A classe Compiler funciona como uma fachada: oferece aos
clientes uma interface única e simples para o subsistema
compilador.
18

19. façade
• O compilador Façade torna a vida mais fácil sem ocultar a
funcionalidade de nível mais baixo dos poucos que a
necessitam.
Figure 6: Classes do subsistema compilador. (Gamma et al., 2006) 19

20. façade
• Aplicabilidade
Quando usar o padrão Façade:
• caso deseje fornecer uma interface simples para um subsistema
complexo.
• caso exista muitas dependências entre clientes e classes de
implementação de uma abstração.
• caso deseje estruturar seus subsistemas em camadas.
20

21. façade
• Estruturas e Participantes
• Façade:
• conhece quais as classes do subsistema são responsáveis pelo
atendimento de uma solicitação;
• delega solicitações de clientes a objetos apropriados do
subsistema.
• Classes de Subsistema:
• implementam a funcionalidade do subsistema;
• encarregam-se do trabalho atribuído a elas pelo objeto Façade;
• não têm conhecimento da façade; isto é, não mantêm referências
para a mesma.
Figure 7: Estrutura e participantes do padrão Façade. (Gamma et al., 2006) 21

22. façade
• Consequências
Benefícios ao se utilizar Façade:
• Isola os clientes dos componentes do subsistema, dessa forma
reduzindo o número de objetos com que os clientes têm que lidar
e tornando o subsistema mais fácil de usar;
• Promove um acoplamento fraco entre o subsistema e seus
clientes;
• Não impede as aplicações de utilizarem as classes do subsistema
caso necessitem fazê-lo. Assim, você pode escolher entre a
facilidade de uso e a generalidade.
22

23. façade
• Implementação
23

24. observação sobre padrões estruturais
• Dependem do mesmo conjunto de mecanismos de linguagem
para a estruturação do código e de objetos: herança simples e
múltipla para padrões baseados em classes e composição de
objetos para padrões de objetos;
• Apresentam intenções diferentes.
24

25. padrões de projetos comportamentais

26. visão geral
1. Contexto
• Preocupam-se com algoritmos e a atribuição de
responsabilidades entre objetos. Os padrões comportamentais
não descrevem apenas padrões de objetos ou classes, mas
também os padrões de comunicação entre eles.
26

27. visão geral
2. Padrões Comportamentais de Classe
• Os padrões comportamentais de classe utilizam a herança para
distribuir o comportamento entre classes.
27

28. visão geral
3. Padrões Comportamentais de Objetos
• Os padrões comportamentais de objeto utilizam a composição
de objetos em vez da herança.
28

29. observer

30. observer
• Intenção: Definir uma dependência um-para-muitos entre
objetos, de maneira que quando um objeto muda de estado
todos os seus dependentes são notificados e atualizados
automaticamente.
• Motivação: Necessidade de separar aspectos de apresentação
dos dados da aplicação.
• Cenário: toolkits para construção de interfaces gráficas de
usuário separam os aspectos de apresentação da interface do
usuário dos dados da aplicação subjacente.
• As classes que definem dados da aplicação e da apresentação
podem ser reutilizadas independentemente.
• Estas classes podem também trabalhar em conjunto.
• A planilha e o gráfico de barras não têm conhecimento um do
outro, desta forma permitindo reutilizar somente o objeto de que
você necessita.
• Ao mudar a informação na planilha, o gráfico de barras reflete as
mudanças imediatamente, e vice-versa.
30

31. observer
• Os objetos-chave nesse padrão são subject (assunto) e
observer (observador).
Figure 8: Apresentação do cenário utilizando observer. (Gamma et al., 2006)
• Um subject pode ter um número qualquer de observadores
dependentes.
• Todos os observadores são notificados quando o subject sofre
uma mudança de estado.
• Cada observador inquirirá o subject para sincronizar o seu
estado com o estado do subject. 31

32. observer
• Aplicabilidade
O padrão Observer pode ser usado em situações:
• quando uma abstração tem dois aspectos dependentes entre si,
de maneira que encapsulando estes aspectos em objetos
separados permite-se variá-los e reutilizá-los
independentemente;
• quando uma mudança em um objeto exige mudanças em outros;
• quando um objeto deve ser capaz de notificar outros objetos.
32

33. observer
• Estrutura e Participantes
Figure 9: Estrutura e Participantes utilizados no padrão observer.
(Gamma et al., 2006)
33

34. observer
• Consequências
Benefícios adicionais e deficiências do padrão Observer
incluem o seguinte:
2. Suporte para comunicações do tipo broadcast;
3. Atualizações inesperadas
34

35. observer
• Implementação
35

36. strategy

37. strategy
• Intenção: Definir uma família de algoritmos, encapsular cada
uma delas e torná-las intercambiáveis. Strategy permite que o
algoritmo varie independentemente dos clientes que o utilizam.
• Motivação: Considere uns algoritmos para quebrar um stream
de texto em linhas. Codificar de maneira fixa e rígida tais
algoritmos nas classes que os utilizam não é desejável.
• Cenário: Criar classes que encapsulam diferentes algoritmos de
quebra de linhas. Este algoritmo encapsulado é chamado de
strategy (estratégia).
• Aplicação: Suponha que uma classe Composition seja
responsável pela manutenção e atualização das quebras de
linhas de texto exibidas num visualizador de texto.
• As estratégias de quebra de linhas não são implementadas pela
classe Composition.
• São implementadas separadamente por subclasses da classe
abstrata Compositor
37

38. strategy
• SimpleCompositor: Implementa uma estratégia com quebras de
linha, uma por vez.
• TeXCompositor: Implementa o algoritmo encontrar quebras de
linhas, otimizando globalmente as quebras de linhas.
• ArrayCompositor: Implementa uma estratégia que seleciona
quebras de maneira que cada linha tenha um número fixo de
itens.
Figure 10: Implementação de quebras de linha usando padrão Strategy.
(Gamma et al., 2006)
38

39. strategy
• Estrutura e Participantes
Figure 11: Estrutura e participantes do padrão Strategy. Gamma et al., 2006
39

40. strategy
• Aplicabilidade
Usar o padrão Strategy quando:
• muitas classes relacionadas diferem somente no seu
comportamento;
• um algoritmo usa dados dos quais os clientes não deveriam ter
conhecimento;
• uma classe define muitos comportamentos, e estes aparecem em
suas operações como múltiplos comandos condicionais da
linguagem.
40

41. strategy
• Consequências
O padrão Strategy tem os seguintes benefícios e desvantagens:
• Famílias de algoritmos relacionados;
• Estratégias eliminam comandos condicionais da linguagem de
programação;
• A possibilidade de escolha de implementações;
• Aumento do número de objetos.
41

42. strategy
• Implementação
42

43. observação sobre padrões comportamentais
• Com poucas exceções, os padrões comportamentais
complementam e reforçam uns aos outros.
• Os padrões comportamentais também funcionam bem com
outros padrões.
43

44. conclusão
• Padrões de projetos estruturais preocupam-se em como
relacionar classes e objetos para gerar estruturas de projetos
maiores, diferenciando-se entre si pelas suas intenções;
• Padrões de projetos comportamentais preocupam-se com os
algoritmos e as responsabilidades entre objetos.
44

45. referência
Gamma, E., Johnson, R., Helm, R., & Vlissides, J. (2006). Padrões de projetos:
soluções reutilizáveis. BOOKMAN COMPANHIA ED. Retrieved from
https://books.google.com.br/books?id=V0Ey1KF3zwcC
45