Padrões de Projeto Estruturais

Apresentação em tema: "Padrões de Projeto Estruturais"— Transcrição da apresentação:

1 Padrões de Projeto Estruturais
Padrões de Projeto Orientados a Objetos Profa. Danielle Martin Universidade de Mogi das Cruzes

2 Padrão de Projeto Descrição da essência de uma solução comum apropriada a um problema conhecido e recorrente. Define boas práticas de programação. Facilita o reuso, flexibilidade e simplicidade do software. Deve ser suficientemente abstrato para ser reutilizado em diferentes aplicações.

3 23 Padrões de projeto – Gang of Four (GoF)
Padrões de Projeto: Soluções reutilizáveis de software orientado a objetos Gang of four: Erich Gamma Richard Helm Ralph Johnson John Vlissides Publicado em Referência no assunto de design patterns.

4 Classificação dos padrões GoF
Criacionais De criação: Dizem respeito à criação de objetos. Estruturais De estrutura: Tratam da composição de classes e objetos. Comportamentais Do comportamento: Tratam da colaboração (interação e responsabilidade) entre classes e objetos.

5 Classificação dos padrões GoF
Os padrões GoF classificados por categorias são: Criação Estrutura Comportamento Classe Factory Class Adapter Interpreter Template Method Objeto Abstract Factory Builder Prototype Singleton Object Adapter Bridge Composite Decorator Facade Flyweight Proxy Chain of Responsibility Command Iterator Mediator Memento Observer State Strategy Visitor

6 Classificação dos padrões GoF
Os padrões GoF classificados por categorias são: Criação Estrutura Comportamento Classe Factory Class Adapter Interpreter Template Method Objeto Abstract Factory Builder Prototype Singleton Object Adapter Bridge Composite Decorator Facade Flyweight Proxy Chain of Responsibility Command Iterator Mediator Memento Observer State Strategy Visitor

7 PADRÃO ADAPTER

8 O problema Uma loja de vendas utiliza objetos Funcionario para controle do pagamento de seus empregados. Os métodos calcularSalarioAnual e calcularSalarioMensal são sobrescritos pelas classes Gerente, Vendedor e Administrativo, devido a diferenças nas regras de cálculo de cada tipo de funcionário.

9 O problema Recentemente, a loja adquiriu uma de suas concorrentes e, ainda que as duas lojas irão operar isoladamente como lojas independentes, a gerência solicitou que ambos os sistemas sejam integrados para que a consulta de salários dos funcionários possa trazer informações de funcionários das duas lojas.

10 O problema No entanto, ao examinar a modelagem do sistema da loja 2, o analista encontrou a seguinte estrutura de classes: A interface Empregado do sistema da Loja 2 disponbiliza um método consultarSalario que recebe o período de consulta como parâmetro (mensal, trimestral ou anual). Este método pode ser utilizado para realizar a consulta desejada pela gerência, mas seu formato é diferente do sistema atual.

11 O problema Como podemos utilizar essas novas classes para integrá-las na aplicação original? ?

12 A solução Podemos criar uma classe Adaptadora, que irá funcionar como um intermediário entre as duas interfaces, adaptando o formato dos métodos da interface Funcionario para os métodos da interface Empregado. Esta é a ideia do padrão Adapter, que permite que uma classe criada com um formato diferente ou externo ao sistema atual possa ser utilizada com as interfaces existentes no mesmo, quase como um adaptador de tomadas do mundo real:

13 A solução Dessa forma, a nova modelagem do sistema ficaria assim:

14 A solução

15 A solução

16 Diferença entre Class Adapter e Object Adapter
Utiliza herança para relacionar o adaptador com o adaptado. Solução mais rígida, pois Java e C# não suportam herança múltipla. Object Adapter Utiliza composição para relacionar o adaptador com o adaptado. Solução mais flexível.

17 PADRÃO BRIDGE

18 O problema Considere o seguinte diagrama das classes de um sistema bancário: Como podemos perceber, existe uma classe abstrata Conta que implementa alguns comportamentos concretos, como sacar, depositar e transferirParaConta. Existem também dois tipos de contas distintas, a ContaCorrente e a ContaPoupança, cada uma com suas particularidades: da conta corrente é cobrada uma tarifa mensal correspondente à uma cesta de serviços e a conta poupança permite a capitalização do dinheiro aplicado, sem nenhuma cobrança de tarifas.

19 O problema O que acontece, no entanto, quando o banco em questão decide criar um novo tipo de conta? Surge assim a ContaMista, uma conta corrente, com sua devida cesta de serviços, mas que também permite a capitalização. Como isso afetaria as classes do nosso sistema?

20 Solução 1? Como já temos uma abstração Conta, basta criar uma nova classe concreta ContaMista, com os comportamentos aplicáveis: Apesar de parecer a solução mais simples à primeira vista, reparem que a operação cobrarTarifa é implementada duas vezes, duplicada entre a a ContaCorrente e a ContaMista, e a operação capitalizar também está duplicada, entre a ContaPoupanca e a ContaMista.

21 Solução 2? Vamos tentar criar novas abstrações que também estendam o comportamento de Conta:

22 Uma classe pode ter apenas uma superclasse.
Solução 2? Quase lá! Mas o Java e outras linguagens não aceitam herança múltipla, como aparece no caso da ContaMista. Uma classe pode ter apenas uma superclasse. Mas se a ContaMista é uma ContaComTarifa e é também uma ContaComCapitalização, e não pode herdar ambas, como vamos resolver esse problema?

23 A solução – Padrão Bridge
Percebemos que há dois comportamentos distintos que se combinam de maneiras diferentes entre os vários tipos de conta. Vamos então usar nossos conhecimentos sobre abstrações de interfaces para isolar esses comportamentos em classes distintas e usar a composição para criar uma “ponte" entre a classe Conta e esses comportamentos. A ideia do Padrão Bridge é desacoplar duas ou mais hierarquias de comportamentos em abstrações diferentes e usar a composição para relacioná-las.

24 A solução – Padrão Bridge
Com essa implementação, podemos inclusive implementar novos tipos de tarifas e de capitalização no futuro, sem prejudicar nossa estrutura. Exemplo:

25 Classe Conta

26 Classes filhas

27 Classe principal

28 PADRÃO COMPOSITE

29 O problema Componentes de hardware podem ser combinados para formar uma peça de hardware, que por sua vez também é um componente e pode ser usado para compor um computador customizado.

30 Anti-padrão Cada composição de componente é modelada individualmente. A solução é complexa e pouco flexível.

31 Anti-padrão Código da classe Computador

32 A solução: padrão Composite
O padrão Composite propõe a composição recursiva para compor objetos de mesmo tipo, a fim de criar objetos compostos em uma estrutura tipo a de árvore.

33 A solução: padrão Composite
Todos os componentes herdam de uma superclasse comum. Componentes compostos (como computador, placa mãe e placa de vídeo) podem ser compostos por outros componentes.

34 Classes Componente e ComponenteComposite

35 Classes HardDisk e Computador
Objeto folha Objeto composite

36 Aplicacao cliente