1 / 72

Padrões de Design

Padrões de Design. Toacy Cavalcante de Oliveira. Problema. 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).

gerek
Download Presentation

Padrões de Design

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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)

More Related