A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

Padrões de Design Toacy Cavalcante de Oliveira. 2 April 20, 2015 Problema.

Apresentações semelhantes


Apresentação em tema: "Padrões de Design Toacy Cavalcante de Oliveira. 2 April 20, 2015 Problema."— Transcrição da apresentação:

1 Padrões de Design Toacy Cavalcante de Oliveira

2 2 April 20, 2015 Problema

3 3 April 20, 2015 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 4 April 20, 2015 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 5 April 20, 2015 Problema Como capturar este conhecimento de modo a transmiti-lo a outros desenvolvedores para que estes também se tornem experts? Design Patterns

6 6 April 20, 2015 Introdução

7 7 April 20, 2015 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 8 April 20, 2015 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 9 April 20, 2015 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 10 April 20, 2015 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 11 April 20, 2015 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 12 April 20, 2015 Histórico

13 13 April 20, 2015 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 14 April 20, 2015 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 15 April 20, 2015 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 16 April 20, 2015 Livros Design Patterns: Elements of Reusable Object-Oriented Software Erich GammaErich Gamma, Richard Helm, Ralph Johnson, John VlissidesRichard HelmRalph JohnsonJohn Vlissides Addison-Wesley, October 1994

17 17 April 20, 2015 Descrevendo Padrões

18 18 April 20, 2015 4 Elementos Essenciais Nome do padrão Problema Solução Conseqüências

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

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

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

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

23 23 April 20, 2015 Exemplo

24 24 April 20, 2015 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 25 April 20, 2015 Observer - Elementos

26 26 April 20, 2015 Catálogo

27 27 April 20, 2015 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 28 April 20, 2015 Estrutura do Catálogo Classifica padrões de acordo com seu propósito,  De Criação  Estrutural  Comportamental e escopo.  Objeto  Classe

29 29 April 20, 2015 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 30 April 20, 2015 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 31 April 20, 2015 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 32 April 20, 2015 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 33 April 20, 2015 Visão Geral

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

35 35 April 20, 2015 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 36 April 20, 2015 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 37 April 20, 2015 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 38 April 20, 2015 Observer

39 39 April 20, 2015 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 40 April 20, 2015 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 41 April 20, 2015 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 42 April 20, 2015 Estrutura

43 43 April 20, 2015 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 44 April 20, 2015 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 45 April 20, 2015 Conseqüências Acoplamento fraco entre o Subject e o Observer Suporte para comunicações em broadcast Atualizações inesperadas

46 46 April 20, 2015 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 47 April 20, 2015 Exemplo de código

48 48 April 20, 2015 Exemplo de código

49 49 April 20, 2015 Exemplo de código

50 50 April 20, 2015 Usos conhecidos Serviço de Eventos e Serviço de Notificação (CORBA)

51 51 April 20, 2015 Padrões relacionados Mediator  Encapsula a semântica de atualizações complexas, o ChangeManager atua como um mediador entre subjects e observers Singleton  o ChangeManager pode usar o padrão singleton para torná-lo único e globalmente acessível.

52 52 April 20, 2015 Catálogo

53 53 April 20, 2015 Catálogo Abstract Factory:  Provê uma interface para criação de famílias de objetos relacionados ou interdependentes. Remove a dependência entre o cliente, que usa os objetos, e a classe dos objetos produzidos. Adapter:  Converte a interface de uma classe em outra, esperada pelo cliente. O Adapter permite que classes que antes não poderiam trabalhar juntas, por incompatibilidade de interfaces, possam agora fazê-lo. Bridge:  Separa uma abstração de sua implementação, de modo que ambas possam variar independentemente. Builder:  Provê uma interface genérica para a construção incremental de agregações. Um Builder esconde os detalhes de como os componentes são criados, representados e compostos. Chain of Responsibility:  Encadeia os objetos receptores e transporta a mensagem através da corrente até que um dos objetos a responda. Assim, separa (provê loose coupling) objetos transmissores dos receptores, dando a chance de mais de um objeto poder tratar a mensagem.

54 54 April 20, 2015 Catálogo de Padrões de Projeto Command:  Encapsula uma mensagem como um objeto, de modo que se possa parametrizar clientes com diferentes mensagens. Separa, então, o criador da mensagem do executor da mesma. Composite:  Compõe objetos em árvores de agregação (relacionamento parte-todo). O Composite permite que objetos agregados sejam tratados como um único objeto. Decorator:  Anexa responsabilidades adicionais a um objeto dinâmicamente. Provê uma alternativa flexível para extensão de funcionalidade, sem ter que usar Herança. Facade:  Provê uma interface unificada para um conjunto de interfaces em um subsistema. O Facade define uma interface alto nível para facilitar o uso deste subsistema. Factory Method:  Define uma interface para criação de um objeto, permitindo que as suas subclasses decidam qual classe instanciar. O Factory Method deixa a responsabilidade de instanciação para as subclasses.

55 55 April 20, 2015 Catálogo Flyweight:  Usa o compartilamento para dar suporte eficiente a um grande número de objetos com alto nível de granularidade. Interpreter:  Usado para definição de linguagem. Define representações para gramáticas e abstrações para análise sintática. Iterator:  Provê um modo de acesso a elementos de um agregado de objetos, sequencialmente, sem exposição de estruturas internas. Mediator:  Desacopla e gerencia as colaborações entre um grupo de objetos. Define um objeto que encapsula as interações dentre desse grupo. Memento:  Captura e externaliza o estado interno de um objeto (captura um "snapshot"). O Memento não viola o encapsulamento.

56 56 April 20, 2015 Catálogo Observer:  Provê sincronização, coordenação e consistência entre objetos relacionados. Prototype:  Especifica os tipos de objetos a serem criados num sistema, usando uma instância protótipo. Cria novos objetos copiando este protótipo. Proxy:  Provê Design para um controlador de acesso a um objeto. Singleton:  Assegura que uma classe tenha apenas uma instância e provê um ponto global de acesso a ela. State:  Deixa um objeto mudar seu comportamento quando seu estado interno muda, mudando, efetivamente, a classe do objeto.

57 57 April 20, 2015 Catálogo Strategy:  Define uma família de algoritmos, encapsula cada um deles, e torna a escolha de qual usar flexível. O Strategy desacopla os algoritmos dos clientes que os usa. Template Method:  Define o esqueleto de um algoritmo em uma operação. O Template Method permite que subclasses componham o algoritmo e tenham a possibilidade de redefinir certos passos a serem tomados no processo, sem contudo alterar sua inetrface. Visitor:  Representa uma operação a ser realizada sobre elementos da estrutura de um objeto. O Visitor permite que se crie um nova operação sem que se mude a classe dos elementos sobre as quais ela opera.

58 58 April 20, 2015 Utilização

59 59 April 20, 2015 Como utilizar Padrões? Existem algumas perguntas que auxiliam o emprego de Design Patterns. A resposta não é exata mas da uma boa direção!

60 60 April 20, 2015 Variação Existe variação de uma regra de negócio ou implementação?  Strategy  Bridge  Proxy  Decorator  Visitor

61 61 April 20, 2015 Ex. Strategy Existe alguma variação na regra?  Define uma família de algoritmos, encapsula cada um deles, e torna a escolha de qual usar flexível. O Strategy desacopla os algoritmos dos clientes que os usa. Ex. Feature Alternativas são candidatas para o Strategy.

62 62 April 20, 2015 Interfaces Existe uma preocupação com interfaces e/ou tratamento de “objetos” incompatíveis?  Adapter  Composite  Facade

63 63 April 20, 2015 Ex. Facade Existe a necessidade de simplificar, “OO- ificar” uma classe ou um subsistema?  Provê uma interface unificada para um conjunto de interfaces em um subsistema. O Facade define uma interface alto nível para facilitar o uso deste subsistema.

64 64 April 20, 2015 Desacoplamanto Existe a necessidade de desacoplar ?  Observer  Chain of Responsibility  Iterator  Mediator  State

65 65 April 20, 2015 Ex. State Existem objetos om muitos estados, implicando e um difícil gerenciamento destes (muito código) ?  Deixa um objeto mudar seu comportamento quando seu estado interno muda, mudando, efetivamente, a classe do objeto.

66 66 April 20, 2015 Criação Existe a necessidade de criar coisas?  Abstract Factory  Builder  Factory Method

67 67 April 20, 2015 Ex. Factory Method As subclasses necessitam saber/descobrir o que instanciar?  Define uma interface para criação de um objeto, permitindo que as suas subclasses decidam qual classe instanciar. O Factory Method deixa a responsabilidade de instanciação para as subclasses.

68 68 April 20, 2015 Mais sobre Padrões

69 69 April 20, 2015 +Padrões Analysis patterns –  Soluções típicas para problemas de análise recorrente.  Analysis Patterns, Fowler; Addison-Wesley, 1996  Applying UML and Patterns, Larman, Prentice-Hall, 1998 Architectural patterns  Veja POSA Idioms  Smalltalk Best Practice Patterns, Beck; Prentice Hall, 1997  Concurrent Programming in Java, Lea; Addison-Wesley, 1997  Advanced C++, Coplien, Addison-Wesley, 1992  Effective C++: 50 Specific Ways to Improve Your Programs and Design (2 nd Edition), Scott Meyers, Addison-Wesley, (September 1997)  More Effective C++: 35 New Ways to Improve

70 70 April 20, 2015 Anti-Patterns Soluções de projeto que não respeitam as regras de bons procedimentos em ES.  Abstração, Flexibilidade e Modularidade http://www.antipatterns.com

71 71 April 20, 2015 Anti-Patterns From http://www.antipatterns.com/briefing/sld006.htm

72 72 April 20, 2015 Referências Adicionais Apostila do Prof. Ivan (no site) Design Patterns Explained: A New Perspective on Object-Oriented Design, Alan Shalloway, James R. Trott, http://www.netobjectives.com/dpexplained/ download/dpmatrix.pdf http://www.netobjectives.com/dpexplained/ download/dpmatrix.pdf


Carregar ppt "Padrões de Design Toacy Cavalcante de Oliveira. 2 April 20, 2015 Problema."

Apresentações semelhantes


Anúncios Google