Padrões de Design

1. Padrões de Design Toacy Cavalcante de Oliveira

2. Problema

3. Análise vs Projeto • Análise • Modela o mundo real. • Usualmente não é “mapeável”para o Projeto pois tende a ser ineficiente/ineficaz. • Projeto • Atribuição de Responsabilidades. • Boas práticas (+Coesão, -Acoplamento)

4. Como compatibilizar os dois mundos? • Tipicamente, bons projetistas são formados após um longo período de experiência. • São hábeis praticantes do conceitos básicos de ES. • Abstração, Flexibilidade e Modularidade

5. Problema • Como capturar este conhecimento de modo a transmiti-lo a outros desenvolvedores para que estes também se tornem experts? • Design Patterns

6. Introdução

7. Definições • “um padrão descreve um problema que se repete várias vezes em um determinado meio, descrevendo o núcleo de sua solução, de modo que esta solução possa ser usada milhares e milhares de vezes." [Christopher Alexander]

8. Definições • Os Padrões de Design formam um conjunto de regras que descrevem como realizar certas tarefas no âmbito do desenvolvimento de software [Pree, 1994].

9. Definições • Um Padrão de Design visa resolver um problema recorrente de design que surge em determinadas situações [Buschmann et al., 1996]. • Os Padrões de Design identificam e definem abstrações que estão acima do nível de uma única classe e de suas instâncias, ou de componentes [Gamma et al., 1994].

10. Motivação para DP • Novos problemas são geralmente similares a problemas já resolvidos anteriormente. • As soluções para problemas similares seguem padrões recorrentes.

11. Benefícios • Servem de guia para a solução do problema. • Ajudam a gerenciar a complexidade do software • Estimulam a aplicação e disseminação de boas práticas da POO. • Definem um vocabulário comum entre os projetistas, o que ajuda na disseminação de soluções bem sucedidas.

12. Histórico

13. De onde vêm? • Christofer Alexander • A Pattern Language, Oxford University Press 1977 • Timeless way of Building, Oxford University Press 1979 • C.A. era arquiteto e identificou uma série de padrões utilizados na construção de edificações.

14. OOPSLA • Em 1987, Ward Cunningham e Kent Beck usaram algumas das idéias de Alexander no trabalho sobre GUI intitulado “Using Pattern Languages for Object-Oriented Programs” [OOPSLA-87].

15. Gang-of-Four • Em 1994, Erich Gamma, Richard Helm, John Vlissides e Ralph Johnson publicaram um dos livros mais importantes de Engenharia de Software da década de 90: “Design Patterns: Elements of Reusable Object-Oriented Software” [GoF].

16. Livros Design Patterns: Elements of Reusable Object-Oriented Software Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides Addison-Wesley, October 1994

17. Descrevendo Padrões

18. 4 Elementos Essenciais • Nome do padrão • Problema • Solução • Conseqüências

19. Nome • Serve de referência para o padrão. • Aumenta o vocabulário de projeto. • Deve ser único.

20. Problema • Quando aplicar um padrão. • Contexto. • Lista de condições que justifiquem aplicar o padrão.

21. Solução • Elementos que compõem o padrão. • “Arranjo” geral dos seus elementos. • Responsabilidades e colaborações destes elementos.

22. Conseqüência • Análises • Vantagens / desvantagens • Flexibilidade, capacidade de extensão ou portabilidade.

23. Exemplo

24. Identificação • Nome: Observer • Problema: Notificar a ocorrência de um evento a uma lista de objetos. • Solução: Observers delegam a responsabilidade de monitoramento para um objeto central o Subject. • Consequencias: Permite variar Subject e Observer de forma independente. Permite comunicação broadcast.

25. Observer - Elementos

26. Catálogo

27. GoF & POSA • GoF (“the gang of four”) catalogue • “Design Patterns: Elements of Reusable Object Oriented Software,” Gamma, Helm, Johnson,Vlissides, Addison-Wesley, 1995 • POSA catalogue • Pattern-Oriented Software Architecture,Buschmann, et al.; Wiley, 1996

28. Estrutura do Catálogo • Classifica padrões de acordo com seu propósito, • De Criação • Estrutural • Comportamental • e escopo. • Objeto • Classe

29. Quanto ao escopo • Classes • Padrões tratam do relacionamento entre classes e subclasses; • Objetos • Padrões tratam relacionamentos entre objetos e por isso podem ser alterados em tempo de execução.

30. De Criação • Diz respeito ao processo ou ciclo de criação de um objeto. • Escopo classe: delega a criação de um objeto para alguma de suas subclasses. • Escopo objeto: delega a criação de um objeto para outro objeto

31. Estrutural • Diz respeito a composição de objetos e classes; • Escopo classe: Utilizam herança para compor objetos • Escopo Objeto: Descreve formas de compor objetos.

32. Comportamental • Caracteriza o modo como classes e objetos interagem e compartilham responsabilidades. • Escopo Classe: Utiliza herança para descrever algoritmos e controle de fluxo. • Escopo Objeto: Descreve como um grupo de objetos cooperam de modo a executar uma tarefa.

33. Visão Geral

34. Estrutura Interna • Além das 4 características essenciais, o Catálogo do GoF define outras características para descrever padrões.

35. Estrutura Interna 1/3 • Nome do Padrão e Classificação • Passa a fazer parte do vocabulário dos projetistas. • Propósito • O quê o Padrão faz? • Que tipo de problema ou característica particular de projeto ele trata? • Também Conhecido Como: • Conjunto de outros nomes (apelidos) conhecidos para o Padrão, se existir algum. • Motivação • Um cenário que ilustra o problema de projeto e como as estruturas de classes e objetos no Padrão o resolvem.

36. Estrutura Interna 2/3 • Aplicação • Quais são as situações onde este padrão pode ser aplicado? • Quais são os exemplos de projetos que ele pode tratar? • Como você pode reconhecer estas situações? • Estrutura • Uma representação gráfica das classes no padrão • Participantes • As classes e/ou objetos que participam no padrão de projeto, e suas responsabilidades • Colaborações • Como os participantes interagem para cumprir suas responsabilidades

37. Estrutura Interna 3/3 • Conseqüências • Como o padrão alcança seus objetivos? • Quais são os resultados do uso do padrão? • Implementação • Dicas e técnicas que o projetista deve saber, e possíveis armadilhas para as quais ele deve estar preparado. • Exemplo de Código • Fragmentos de código que ilustram como o padrão deve ser implementado • Usos Conhecidos • Exemplos de utilização do padrão em sistemas já implementados. • Padrões Relacionados • Lista de alguns padrões fortemente relacionados ao padrão em questão e as suas principais diferenças.

38. Observer

39. O padrão Observer • Classificação • Comportamental de Objetos • Propósito • Provê sincronização, coordenação e consistência entre objetos relacionados. • Também Conhecido Como: • Dependents, Publish-Subscribe

40. Motivação • Necessidade de manter consistência entre objetos relacionados. • Não existe interesse em tornar as classes fortemente acopladas. • Ex. Planilha e gráfico de barras. • Não tem conhecimento um do outro • Trabalham em conjunto apresentando uma mesma informação • O padrão observer oferece um mecanismo para resolver esse problema • Subject Possui um conjunto de observers. • Notifica seus observers quando sofre uma mudança de estado

41. Aplicabilidade • Quando uma mudança em um objeto exige mudanças em outros, e não são conhecidos quantos devem ser mudados. • Quando um objeto deve ser capaz de notificar outros objetos sem que estes sejam fortemente acoplados.

42. Estrutura

43. Participantes • Subject • conhece seu Observer. Qualquer número de objetos Observer podem observar um Subject • provê uma interface para acoplar e desacoplar objetos Observer. • ConcreteSubject • guarda o estado de interesse para ConcreteObserver • envia uma notificação para seu Observer quando seu estado muda. • Observer • define uma interface de atualização para objetos que devem ser notificados sobre mudanças em um Subject. • ConcreteObserver • Mantém uma referência para um objeto ConcreteSubject • Guarda o estado que deve ficar consistente com o de Subject • Implementa o Observer atualizando a interface para manter seu estado consistente com o de Subject.

44. Colaborações • O ConcreteSubject notifica seus observadores sempre que ocorrer uma mudança. • Após ter sido notificado, um ConcreteObserver pode consultar o subject.

45. Conseqüências • Acoplamento fraco entre o Subject e o Observer • Suporte para comunicações em broadcast • Atualizações inesperadas

46. Implementação • Observando mais de um subject • Subject ativador é passado como parâmetro no método update() • Quem dispara a atualização? • Subject • Cliente

47. Exemplo de código

48. Exemplo de código

49. Exemplo de código

50. Usos conhecidos • Serviço de Eventos e Serviço de Notificação (CORBA)