Decorator Pattern. SISMO - Sistemas e Mobilidade Junho de Departamento de Informática / UFMA

Transcrição

1 Decorator Pattern SISMO - Sistemas e Mobilidade Departamento de Informática / UFMA Junho de 2008

2 Revisando os conceitos Herança é poderosa mas não é flexível Comportamento herdado nas subclasses é fixado na compilação Todas as subclasses herdam o mesmo comportamento Composição e Delegação permitem reúso flexível de comportamento Composição permite estender o comportamento do objeto dinamicamente na execução Isso é possível porque não é necesário modificar o código existente Pelo mesmo motivo, as chances de introdução de erros são reduzidas

3 Princípio O.O: Estender sem Modificar Classes devem ser abertas para extensão e fechadas para modificação A meta é permitir que classes sejam facilmente estendidas para incorporar novos comportamentos sem modificar o código existente Desejamos obter projetos resilientes a mudanças, suficientemente flexíveis para atender novas funcionalidades e requisitos Como atender essa meta um tanto contraditória? Uso de técnicas O.O provadas e aprovadas (padrões) O princípio não deve ser aplicado de forma generalizada, mas sobretudo em pontos do projeto mais suscetíveis a mudanças Identificar esses pontos depende da experiência do projetista sobre o domínio e em problemas semelhantes

4 O Problema do Ressaca s Bar O Ressaca s é o bar de maior sucesso da região. A razão é a variada oferta de drinks a disposição dos clientes. Por outro lado, o sistema de pedidos do bar se tornou mais complexo e está difícil mantê-lo por conta da grande variedade de drinks Vamos ver como o problema começou...

5 Diagrama de Classes dos Drinks Figura: Diagrama Original

6 Onde está o busílis? O problema é que a pedido dos clientes, novos drinks foram criados pela adição de diferentes aditivos aos drinks existentes Os projetistas criaram novas classes para representar os novos drinks e calcular os preços de cada um deles levando em conta os diferentes ingredientes em decorrência houve uma verdadeira explosão de classes para representar os diferentes tipos de drinks Um pesaselo de manutenção... além de violar dois princípios O.O. Quais?

7 Princípios O.O violados Encapsule os aspectos mais sujeitos a mudanças Prefira Composição/Delegação em vez de Herança

8 Experimentando uma solução Figura: Solução baseada em variáveis de instância

9 Experimentando uma solução II Figura: Calculando preços dos drinks

10 Solução baseada em variáveis de instância O método price na classe Drink calcula os preços associados aos ingredientes Nas subclasses, o método price calcula o preço básico do drink e chama o método price da classe Drink para calcular os preços dos condimentos que são parte do drink Quais os problemas com essa solução?

11 Fatores que podem mudar afetando o design A adição de novos ingredientes obriga a adicionar novos métodos e a alterar o método price na superclasse Nem todos os ingredientes são adequados para todos os drinks; no entanto, os métodos associados a esses ingredientes são herdados por todas as subclasses E se alguém quiser uma dose dupla de apenas alguns dos ingredientes?

12 A abordagem Decorator I Figura: Tome um objeto BaseCaipirinha

13 A abordagem Decorator II Figura: Decore-o com um objeto Cachaca

14 A abordagem Decorator III Figura: Decore-o com um objeto Adocante Chame o método price e use delegação para calcular os preços dos ingredientes adicionais

15 Características da Abordagem Decoradores empacotam os objetos decorados Decoradores têm o mesmo supertipo dos objetos que eles decoram Objetos são decorados em camadas O decorador pode adicionar o seu próprio comportamento antes ou depois de delegar ao objeto que decora a responsabilidade de continuar o trabalho Objetos podem ser decorados dinamicamente em tempo de execução

16 Padrão Decorator Classificação: Propósito: Estrutural Escopo: Objetos Intenção: agregar, dinamicamente, responsabilidades adicionais a a objetos individuais, e não a toda uma classe. São uma alternativa flexível ao uso de subclasses para extensão de funcionalidades a.k.a.: Wrapper

17 Aplicabilidade Quando se deseja crescentar responsabilidades a objetos individuais de forma dinâmica e transparente Para permitir a remoção de responsabilidades também dinamicamente Quando a extensão através de subclasses não é prática Por exemplo, quando há possibilidade de explosão do número de subclasses

18 Estrutura do Decorator Figura: Estrutura Motivação: Adicionar responsabilidades a objetos individuais, e não a toda uma classe

19 Participantes Component: define a interface para objetos que podem ter responsabilidades acrescentadas dinamicamente ConcreteComponent: define um objeto para o qual responsabilidades adicionais podem ser atribuídas Decorator: define uma interface que segue a de Component e mantém uma referência para um objeto Component ConcreteDecorator: acrescenta responsabilidades ao component

20 Colaborações no Decorator Decorator repassa solicitações para seus objeto Component e pode, opcionalmente, executar operações adicionais antes e depois de repassar a solicitação

21 Ressaca s Decorator Figura: Diagrama de Classes

22 Codificando o sistema - Classe Raiz e Decorador Figura: Classes Drink e AditivoDecorator

23 Codificando o sistema - Classes Concretas Figura: Classe BaseCaipirinha

24 Codificando o sistema - Classes Concretas Figura: Classe Cocktail

25 Codificando o sistema - Um Decorador Concreto Figura: Classe Cachaca

26 Sistema Ressaca s Figura: Implementando o sistema

27 Exemplo com Widgets Figura: Decorando widgets Adicionando propriedades, como bordas, ou comportamentos, como rolamento, a componentes de uma interface de usuário, apenas quando for necessário

28 Decorador para Widgets Figura: Diagrama de Classes

29 Exemplo de código Figura: Classes Component e Decorator

30 Exemplo de código II Decorator decora o VisualComponent referenciado por component, que é inicializado no construtor Para cada operação na interface de VisualComponent, Decorator define uma implementação que passa a solicitação para component: Figura: Métodos de Decorator

31 Exemplo de código III Figura: Classe BorderDecorator

32 Exemplo de código IV Figura: Inserindo a Classe TextView

33 Exemplo de código V Figura: Código cliente

34 Consequências do uso do Decorator Maior flexibilidade que a herança (estática) Evita classes sobrecarregadas de características na parte superior da hierarquia Grande quantidade de pequenos objetos. Padrões de criação como Builder e Factory ajudam a criar objetos no padrão Decorator O uso do Decorator é mais apropriado se não for necessário conhecer os tipos concretos dos objetos encapsulados