1 Introdução aos Padrões de Projetos (na prática) Créditos: Adaptações: Prof. Nécio de Lima Veras.

Apresentação em tema: "1 Introdução aos Padrões de Projetos (na prática) Créditos: Adaptações: Prof. Nécio de Lima Veras."— Transcrição da apresentação:

1 1 Introdução aos Padrões de Projetos (na prática) Créditos: Adaptações: Prof. Nécio de Lima Veras

2 Padrões de Projeto de Software OO 2 Estudando uns padrões específicos Na semana passada De Criação:  Singleton;  Abstract Factory; Nesta Semana Estrutural:  Decorator; Comportamental:  Observer;  Strategy;

3 3 Padrões Estruturais Decorator

4 Padrões de Projeto de Software OO Queremos modelar estas mesas em termos de objetos Isto é uma mesa! 1 Isto é uma mesa com rodinhas! 2 Isto é uma mesa de ping pong com rodinhas! 3 A aplicação pode, em algum momento, usar a mesa pura, em outro, com rodinhas, em outro, com rede de ping pong, etc. Motivação

5 Padrões de Projeto de Software OO Usar herança? Solução mais “natural”; Adição estática de responsablidades; Cliente não tem como controlar como e quando colocar rodinhas, a rede de ping-pong ou outras coisas:  Responsabilidade é atribuída a classe e não a cada objeto Não é facilmente extensível; E se quisermos usar a mesa para jantar?

6 Padrões de Projeto de Software OO Por que não decorar? Embelezar a mesa com objeto que adiciona rodinhas, outro objeto que adiciona rede de ping-pong, etc. Cada objeto que “embeleza” a mesa é um decorator Solução mais flexível pois podemos aproveitar os decorators para outros móveis e combiná-los de inúmeras formas.  Isto é, Composição de objetos!

7 Padrões de Projeto de Software OO 7 Motivação Em um editor de documentos, queremos “embelezar” a interface do usuário (UI)  Vamos adicionar uma borda à área de edição  Vamos adicionar barras de rolagem (scroll bars)

8 Padrões de Projeto de Software OO 8 Motivação Desejamos adicionar responsabilidades a objetos, individualmente, e não a uma classe; Não vamos usar herança para adicionar este embelezamento:  Não poderíamos mudar o embelezamento em tempo de execução;  Para n tipos de embelezamento, precisaríamos de 2n classes para ter todas as combinações; Teremos mais flexibilidade se outros objetos da UI não souberem que está havendo embelezamento.

9 Padrões de Projeto de Software OO 9 Motivação Usaremos composição de objetos, mas quais objetos devem participar da composição? O embelezamento em si será um objeto (digamos uma instância da classe Border) que embelezará uma instância de TextView  quem vai compor quem? Uma restrição importante é que clientes devem tratar apenas de objetos VisualComponent e não deveriam saber se um TextView tem uma borda ou não.

10 Padrões de Projeto de Software OO 10 Decorator é uma classe abstrata para componentes visuais que embelezam outros componentes visuais; As classes ScrollDecorator e BorderDecorator são subclasses de Decorator:

11 Padrões de Projeto de Software OO Sobre o Decorator O decorator implementa a mesma interface dos componentes que ele decora;  Transparência para os clientes; Decorators podem ser aninhados recursivamente permitindo um número ilimitado de funcionalidades; O decorator adiciona funcionalidades de forma transparente  O component não conhece seus decorators;

12 Padrões de Projeto de Software OO 12 Quando usar? (Applicability) Use o padrão Decorator  Para adicionar responsabilidades a objetos individualmente e de modo transparente, ou seja, sem afetar outros objetos;  Quando há responsabilidades que podem ser retiradas;  Quando a utilização de herança para estender funcionalidades gera uma explosão de subclasses para atender às diversas combinações.

13 Padrões de Projeto de Software OO 13 Estrutura

14 Padrões de Projeto de Software OO 14 Participantes Component  define a interface para objetos que podem ter responsabilidades acrescentadas a eles dinamicamente. ConcreteComponent  define um objeto para o qual responsabilidades adicionais podem ser atribuídas. Decorator  mantém uma referência para um objeto Component e define uma interface que segue a interface de Component. ConcreteDecorator  acrescenta responsabilidades ao componente.

15 Padrões de Projeto de Software OO 15 Colaborações Decorator encaminha pedidos para o objeto Component que ele embeleza; Decorator pode, opcionalmente, realizar operações adicionais antes e após encaminhar o pedido.

16 Padrões de Projeto de Software OO 16 Conseqüências Vantagens  Maior flexibilidade do que a herança estática;  Evita classes sobrecarregadas de características na parte superior da hierarquia;  Adição de responsabilidades por demanda;  Transparência para o Cliente; Desvantagens  Um decorator e o seu componente não são idênticos;  Grande quantidade de pequenos objetos;

17 17 Padrões Comportamentais Strategy Observer

18 18 Strategy

19 Padrões de Projeto de Software OO 19 Motivação Existem muitos algoritmos para quebrar um texto em linhas, cada um seguindo uma estratégia:  Simples  TeX-like: parágrafo  Array-like: Fixa o número de itens por linha

20 Padrões de Projeto de Software OO 20 Motivação Considere uma classe chamada Composition, responsável por manter e atualizar as quebras de linha de um texto mostrado em um editor. void Composition::Repair () { switch (_breakingStrategy) { case SimpleStrategy: ComposeWithSimpleCompositor(); break; case TeXStrategy: ComposeWithTeXCompositor(); break; //... } // merge results with existing // composition, if necessary } Composition int _breakingStrategy; Traverse() Repair() ComposeWithSimpleCompositor() ComposeWithTeXCompositor()

21 Padrões de Projeto de Software OO 21 Motivação Colocar os algoritmos nas classes que necessitam deles não é recomendável pois:  Os clientes podem ficar complexos, em especial se houver muitos algoritmos.  Diferentes algoritmos serão apropriados em variadas circunstâncias. Não queremos dar suporte a diversos algoritmos se não vamos precisar de todos eles.  Tornar o algoritmo parte do cliente dificulta adição de novos algoritmos e extensão dos existentes.

22 Padrões de Projeto de Software OO 22 Motivação Estes problemas podem ser evitados se definirmos classes que encapsulam os diferentes algoritmos de quebra de linha; Um algoritmo encapsulado desse modo é chamado de strategy.

23 Padrões de Projeto de Software OO 23 Motivação (2) Uma aplicação requer que um algoritmo de sort possa ser escolhido em tempo de execução para classificar um array de elementos; Há muitos algoritmos de sort disponíveis. Como permitir isso?

24 Padrões de Projeto de Software OO 24 Motivação (2) Encapsulando os algoritmos de classificação em classes que possuem o método sort()

25 Padrões de Projeto de Software OO 25 Strategy Objetivo  Definir uma família de algoritmos, encapsular cada um, e torná-los intercambiáveis;  Strategy permite mudar os algoritmos independentemente dos clientes que os usam; Também conhecido como  Policy Object Behavioral

26 Padrões de Projeto de Software OO 26 Quando usar? Várias classes relacionadas têm apenas comportamentos diferentes; Você precisa de variantes de um algoritmo:  Exemplo: trade-offs diferentes de espaço-tempo; Para esconder dos clientes os dados complexos que um algoritmo usa; Uma classe tem vários comportamentos escolhidos através de comandos de seleção (if, case, etc.)  Em vez de usar comandos de seleção, mova os trechos apropriados para sua própria classe Strategy;

27 Padrões de Projeto de Software OO 27 Estrutura

28 Padrões de Projeto de Software OO 28 Participantes Strategy (Compositor)  Declara uma interface comum para todos os algoritmos. Context usa essa interface para chamar o algoritmo definido através de uma ConcreteStrategy. ConcreteStrategy (SimpleCompositor, TeXCompositor, ArrayCompositor)  Implementa o algoritmo usando a interface definida em Strategy Context (Composition)  É configurado com um objeto ConcreteStrategy  Mantém uma referência para um objeto Strategy  Pode definir uma interface para que Strategy tenha acesso a seus dados

29 Padrões de Projeto de Software OO 29 Colaborações O objeto Context pode passar todos os dados para um objeto Strategy para execução do algoritmo. O objeto Context encaminha pedidos de seus clientes para sua estratégia Clientes normalmente criam e passam um objeto ConcreteStrategy para Contexto  A partir daí, os clientes interagem apenas com o Context Em geral, há uma família de classes ConcreteStrategy para o cliente escolher uma.

30 Padrões de Projeto de Software OO 30 Consequências Strategy favorece a organização de algoritmos em famílias, para reuso; Strategy é uma alternativa à herança; Strategy elimina comandos condicionais; Strategy permite a escolha entre algoritmos; Pontos negativos  Alguns ConcreteStrategy podem não usar informações na interface de Strategy;  Transparência incompleta dos 2 objetos; cliente precisa saber detalhes;  Mais objetos no projeto;

31 31 Observer

32 Padrões de Projeto de Software OO 32 O Padrão Observer Propósito  Definir uma dependência um-para-muitos entre objetos para que quando um objeto mudar de estado, todos os seus dependentes sejam notificados e atualizados automaticamente. Também Conhecido Como:  Dependents, Publish-Subscribe

33 Padrões de Projeto de Software OO 33 Motivação

34 Padrões de Projeto de Software OO 34 Motivação Como garantir que objetos que dependem de outro objeto fiquem em dia com mudanças naquele objeto?  Como fazer com que os observadores tomem conhecimento do objeto de interesse?  Como fazer com que o objeto de interesse atualize os observadores quando seu estado mudar? Possíveis riscos  Relacionamento (bidirecional) implica alto acoplamento.  Como podemos eliminar o relacionamento bidirecional?

35 Padrões de Projeto de Software OO 35 Estrutura

36 Padrões de Projeto de Software OO 36 Participantes Subject  Conhece seus objetos 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.

37 Padrões de Projeto de Software OO 37 Quando devo usar? Quando uma abstração tem dois aspectos, um dependente do outro. Encapsulando-se esses aspectos em objetos separados fará com que se possa variá-los e reusá-los independentemente; Quando uma mudança em um objeto requer uma mudança em outros, e não se sabe como esses outros objetos efetivamente fazem suas mudanças; Quando um objeto deve poder notificar outros objetos sem assumir nada sobre eles. Dessa forma evita-se que os objetos envolvidos fiquem fortemente acoplados.

38 Padrões de Projeto de Software OO 38 Conseqüências Possibilita baixo acoplamento entre os objetos dependentes (os observadores) e o assunto; Acoplamento Abstrato; Suporte para broadcast; Dificuldade em saber o que foi mudado?

39 Padrões de Projeto de Software OO 39 Implementação Observando mais de um subject  Subject ativador é passado como parâmetro no método update()

40 Padrões de Projeto de Software OO 40 Exemplo getX():int getY():int getColor():Color addObserver(Observer) removeObserver(Observer) notify() setX(int) setY(int) setColor(Color) Point getP1():Point getP2():Point getColor():Color addObserver(Observer) removeObserver(Observer) notify() setP1(Point) setP2(Point) setColor(Color) Line FigureElementFigure 1 * update() Display(String) Screen update() > Observer addObserver(Observer) removeObserver(Observer) notify() > Subject