Padrões de Projeto Composite Observer Strategy Factory Method Mediator Façade.

Apresentação em tema: "Padrões de Projeto Composite Observer Strategy Factory Method Mediator Façade."— Transcrição da apresentação:

1 Padrões de Projeto Composite Observer Strategy Factory Method Mediator Façade

2 Composite  Problema Imagine que você está fazendo um sistema de gerenciamento de arquivos. É possível criar arquivos concretos (vídeos, textos, imagens, etc.) e arquivos pastas, que armazenam outros arquivos. O problema é o mesmo, como fazer um design que atenda estes requerimentos?

3 Composite  Uma Solução Pode-se criar uma classe que represente arquivos que são Pastas, estas pastas teriam uma lista de arquivos concretos e uma lista de arquivos de pastas. Então pode-se adicionar pastas e arquivos em uma pasta e, a partir dela navegar pelas suas pastas e seus arquivos.

4 Composite

5 O problema com este design é a interface que esta classe deverá ter. Como são duas listas diferentes será necessário métodos específicos para tratar cada uma delas, ou seja, um método para inserir arquivos e outro para inserir pastas, um método para excluir pastas e outro para excluir arquivos, e assim vai.

6 Composite Sempre que for necessário inserir uma nova funcionalidade no gerenciador precisará criar a mesma funcionalidade para arquivos e pastas. Além disso, sempre que for necessário percorrer uma pasta será necessário percorrer as duas listas, mesmo que vazias.

7 Composite  Outra Solução E se pudéssemos utilizar uma classe base Arquivo para todos os arquivos, assim precisaríamos apenas de uma lista e de um conjunto de funções.

8 Composite Pronto, resolvido o problema dos métodos duplicados. E agora, será que está tudo bem?

9 Composite Como faríamos a diferenciação entre um Arquivo e uma Pasta? Pode-se utilizar o “instace of” e verificar qual o tipo do objeto, o problema é que seria necessário fazer isso SEMPRE, pois não pode-se confiar que, dado um objeto qualquer, ele é um arquivo ou uma pasta.

10 Composite Sempre teríamos que fazer isso.

11 Composite  Uma boa solução “Compor objetos em estruturas de árvore para representar hierarquia. Composite permite aos clientes tratarem de maneira uniforme objetos individuais e composições de objetos.”

12 Composite A ideia do Composite é criar uma classe base que contém toda a interface necessária para todos os elementos e criar um elemento especial que agrega outros elementos.

13 Composite A classe base Arquivo implementa todos os métodos necessários para arquivos e pastas, no entanto considera como implementação padrão a do arquivo, ou seja, caso o usuário tente inserir um arquivo em outro arquivo uma exceção será disparada.

14 Composite

15 Na classe que representa a pasta pode-se sobrescrever o comportamento padrão e repassar a chamada para todos os arquivos, sejam arquivos ou pastas.

16

17 Composite Com isto não é necessário conhecer a implementação dos objetos concretos, muito menos fazer cast. Veja como poderíamos utilizar o código do Composite:

18

19 Composite Visualizando a tal estrutura de árvore, suponha que temos pastas dentro de pastas com arquivos, a estrutura seria parecida com a de uma árvore, veja a seguir:

20 Composite

21 Como uma estrutura de árvore tem-se Nós e Folhas. No padrão Composite os arquivos concretos do nosso exemplo são chamados de Folhas, pois não possuem filhos e os arquivos pasta são chamados de Nós, pois possuem filhos e fornecem operações sobre esses filhos.

22 Composite Uma das vantagens, e talvez a mais forte, seja o fato de os clientes do código Composite serem bem simplificados, pois podem tratar todos os objetos da mesma maneira. No exemplo, utilizou-se exceções para que ficasse mais evidente quando um método de uma Pasta é chamado em um Arquivo.

23 Composite No entanto, o mal tratamento das exceções pode gerar problemas de segurança e ai surge uma outra forma de implementar o padrão, restringindo a interface comum dos objetos. Para isto basta remover os métodos de gerenciamento de arquivos (adicionar, remover, etc) da classe base, assim apenas os arquivos pastas teriam estes métodos.

24 Observer

25  Problema Suponha que em um programa é necessário fazer várias representações de um mesmo conjunto de dados. Este conjunto de dados consiste de uma estrutura que contém 3 atributos: valorA, valorB e valorC,

26 Observer

27 Com exemplo considera-se que é necessário representar dados em uma tabela, que simplesmente exibe os número, uma representação em gráficos de barras, onde os valores são exibidos em barras e outra representação em porcentagem, relativo a soma total dos valores.

28 Observer A representação deve ser feita de modo que qualquer alteração no conjunto de dados compartilhados provoque alterações em todas as formas de representação, garantindo assim que uma visão nunca tenha dados invalidados.

29 Observer A representação deve ser feita de modo que qualquer alteração no conjunto de dados compartilhados provoque alterações em todas as formas de representação, garantindo assim que uma visão nunca tenha dados invalidados. E que as representações só sejam redesenhadas somente quando necessário. Ou seja, sempre que um valor for alterado.

30 Observer Uma primeira solução poderia ser manter uma lista com as possíveis representações e ficar verificando por mudanças no conjunto de dados, assim que fosse feita uma mudança, as visualizações seriam avisadas.

31 Observer O problema é que precisaria sempre verificar se houve ou não mudança no conjunto de dados, dessa forma o processamento seria muito caro, ou então a atualização seria demorada.

32 Observer  Definição “Definir uma dependência um para muitos entre objetos, de maneira que quando um objeto muda de estado todos os seus dependentes são notificados e atualizados automaticamente.”

33 Observer O padrão Observer parece ser uma boa solução para o problema, pois ele define uma dependência um para muitos, que será necessária para fazer a relação entre um conjunto de dados e várias representações, além de permitir que, quando um objeto mude de estado, todos os dependentes sejam notificados.

34 Observer Para garantir isto o padrão faz o seguinte: cria uma classe que mantém o conjunto de dados e uma lista de dependentes deste conjunto de dados, assim a cada mudança no conjunto de dados, todos os dependentes são notificados.

35 Observer

36 Inicialmente define-se a lista de observadores (DadosObserver é uma interface comum aos observadores e será definida a seguir) e o conjunto de dados a ser compartilhado. Também foram definidos os métodos para adicionar e remover observadores, assim cada novo observador poderá facilmente acompanhar as mudanças.

37 Observer Dentro da mesma classe, pode-se definir as mudanças no estado, ou seja o conjunto de dados:

38 Observer Sempre que for feita uma mudança no conjunto de dados, utilizando o método “setState()” é chamado o método que vai notificar todos os observadores, executando um update para informar que o conjunto de dados mudou.

39 Observer Vamos ver então como seria um observador. Vamos definir então a interface comum a todos os observadores, que é utilizada para manter a lista de observadores na classe que controla o conjunto de dados.

40 Observer

41 Definida a interface vamos então construir o observador que mostra os dados em uma tabela.

42 Observer Este observador simplesmente exibe o valor dos dados. Assim, quando o método update for chamado ele irá redesenhar a tabela de dados.

43 Observer Outros observers podem definir outras maneiras de mostrar o conjunto de dados, por exemplo o observer que exibe os valores em porcentagem.

44 Observer

45

46 Na nomenclatura do padrão Observer tem-se as duas classes principais: Subject e Observer. O Subject é o que mantém os dados compartilhados e a lista de observadores que compartilham o dado. O Observer é o que faz utilização dos dados compartilhados e deve ser atualizado a cada modificação.

47 Strategy

48  Problema Suponha uma empresa, nesta empresa existem um conjunto de cargos, para cada cargo existem regras de cálculo de imposto, determinada porcentagem do salário deve ser retirada de acordo com o salário base do funcionário.

49 Strategy  Problema Vamos as regras: O Desenvolvedor deve ter um imposto de 15% caso seu salário seja maior que R$ 2000,00 e 10% caso contrário; O Gerente deve ter um imposto de 20% caso seu salário seja maior que R$ 3500,00 e 15% caso contrário; O DBA deve ter um imposto de de 15% caso seu salário seja maior que R$ 2000,00 e 10% caso contrário;

50 Strategy  Uma solução Uma solução bem simples seria criar uma classe para representar um funcionário e dentro dele um campo para guardar seu cargo e salário. No método de cálculo de imposto utilizaríamos um switch para selecionar o cargo e depois verificaríamos o salário, para saber qual a porcentagem de imposto que deve ser utilizada.

51 Strategy

52  Este método é uma ótima prova do porque existem tantas vagas para desenvolvimento de software por ai...

53 Strategy  Pense na seguinte situação: Surgiu um novo cargo que precisa ser cadastro, este cargo deve utilizar as mesmas regras de negócio do cargo DBA. O que seria necessário para incluir esta nova funcionalidade? Um novo case com novos if e else. Fácil não?

54 Strategy  Imagine agora que depois de todo o trabalho para inserir todos os possíveis cargos de uma empresa, e uma regra muda? Seria awesome dar manutenção neste código não?

55 Strategy  Padrão Strategy “Definir uma família de algoritmos, encapsular cada uma delas e torná-las intercambiáveis. Strategy permite que o algoritmo varie independentemente dos clientes que o utilizam”

56 Strategy Ou seja, o padrão sugere que algoritmos parecidos (métodos de cálculo de Imposto) sejam separados de que os utiliza (Funcionário).

57 Strategy Certo, e como fazer isso? A primeira parte é encapsular todos os algoritmos da mesma família. No exemplo dado a família de algoritmos é a que calcula salários com impostos, então para encapsulá-las criamos uma classe interface (Java)

58 Strategy Uma vez definida a classe que encapsula os algoritmos define-se as estratégias concretas de cálculo de imposto, a seguir o código para cálculo de imposto de 15% ou 10%:

59 Strategy As outras estratégias seguem este mesmo padrão. Na classe Funcionário. Esta classe depende da classe CalculoImposto, ou seja, ela utiliza um objeto CalculoImposto. Mas, como utilizar um objeto interface? Este objeto será instanciado em tempo de execução e, de acordo com o Cargo dele a estratégia de cálculo correta será utilizada.

60 Strategy

61 E agora a única coisa que precisa ser feita é calcular o salário com imposto.

62 Strategy O padrão Strategy, além de encapsular os algoritmos da mesma família também permite a reutilização do código. No exemplo a regra para cálculo do imposto do Desenvolvedor e do DBA são as mesmas, ou seja, não será necessário escrever código extra.

63 Strategy As classes de estratégia são chamadas de Comportamento e a classe que utiliza o comportamento é chamada de Contexto. Ou seja, para um determinado Contexto você pode aplicar um conjunto de comportamentos.

64 Strategy Outra vantagem é a facilidade para extensão das funcionalidades. No exemplo dado, caso seja necessário incluir um novo cargo basta implementar sua estratégia de cálculo de imposto ou reutilizar outra. Nenhuma outra parte do código precisa ser alterada.

65 Strategy  Problemas Quando outra pessoa está utilizando seu código ela pode escolher qualquer comportamento para o contexto que ela deseja aplicar. Isso pode ser visto como um potencial problema, pois o usuário do seu código deve conhecer bem a diferença entre as estratégias para saber escolher qual se aplica melhor ao contexto dele.

66 Strategy Outra vantagem é a facilidade para extensão das funcionalidades. No exemplo dado, caso seja necessário incluir um novo cargo basta implementar sua estratégia de cálculo de imposto ou reutilizar outra. Nenhuma outra parte do código precisa ser alterada.

67 Strategy Outro potencial problema é a comunicação entre a classe de Contexto e a classe de Comportamento. Suponha um conjunto de dados (contexto) e vários algoritmos de ordenação (comportamento), caso a passagem do conjunto de dados para o algoritmo não seja eficiente a execução do algoritmo vai acabar sendo prejudicada. Da mesma forma, o contexto pode desperdiçar tempo passando dados para um contexto que não precisa deles. Ou seja, vale gastar algum tempo pensando bem em como a comunicação Contexto-Comportamento será feita.

68 Factory Method

69  Problema Suponha que você deve trabalhar em um projeto computacional com um conjunto de carros, cada um de uma determinada fábrica. Para exemplificar suponha os quatro seguintes modelos/fabricantes:  Palio – Fiat  Gol – Volkswagen  Celta – Chevrolet  Fiesta – Ford

70 Factory Method Será necessário manipular este conjunto de carros em diversas operações, como poderíamos modelar este problema?

71 Factory Method Uma primeira solução, mais simples, seria criar uma classe para representar cada carro, no entanto ficaria muito difícil prever as classes ou escrever vários métodos iguais para tratar cada um dos tipos de objetos.

72 Factory Method Poderíamos então criar uma classe base para todos os carros e especializá-la em subclasses que representem cada tipo de carro, assim, uma vez definida uma interface comum poderíamos tratar todos os carros da mesma maneira.

73 Factory Method O problema surge quando vamos criar o objeto, pois, de alguma forma, precisamos identificar qual objetos queremos criar. Ou seja, precisaríamos criar uma enumeração para identificar cada um dos carros e, ao criar um carro, identificaríamos seguindo essa enumeração.

74 Factory Method Classe de criação de carros.

75 Factory Method Esta implementação já corresponde a uma implementação do Factory Method, pois um método fábrica cria Objetos concretos que só serão definidos em tempo de execução. No entanto, esta implementação traz um problema quanto a manutenibilidade do código, pois, como utilizamos um switch para definir qual objeto criar, a cada criação de um novo modelo de carro precisaríamos incrementar este switch e criar novas enumerações.

76 Factory Method Como resolver este problema?

77 Factory Method “Definir uma interface para criar um objeto, mas deixar as subclasses decidirem que classe instanciar. O Factory Method permite adiar a instanciação para subclasses.”

78 Factory Method Ou seja, ao invés de criar objetos diretamente em uma classe concreta, nós definimos uma interface de criação de objetos e cada subclasse fica responsável por criar seus objetos. Seria como se, ao invés de ter uma fábrica de carros, nós tivéssemos uma fábrica da Fiat, que cria o carro da Fiat, uma fábrica da Ford, que cria o carro da Ford e etc.

79 Factory Method

80

81 As outras fábricas seguem a mesma ideia, cada uma define o método de criação de carros e cria o seu próprio carro.

82 Factory Method Agora que vimos as classes fábricas, vamos analisar os produtos. Como já discutimos antes, vamos criar uma interface comum para todos os carros, assim poderemos manipulá-los facilmente.

83 Factory Method Os produtos concretos seriam definidos da seguinte maneira:

84 Factory Method

85 A principal vantagem em utilizar o padrão Factory Method é a extrema facilidade que temos para incluir novos produtos. Não é necessário alterar NENHUM código, apenas precisamos criar o produto e a sua fábrica. Todo o código já escrito não será alterado.

86 Factory Method No entanto isto tem um custo. Criou-se uma estrutura relativamente grande para resolver o pequeno problema, temos um conjunto grande de pequenas classes, cada uma realizando uma operação simples. Para cada novo produto precisa-se sempre criar duas classes, uma produto e uma fábrica.

87 Factory Method Na primeira sugestão de implementação nós definimos o Factory Method em uma classe concreta, isso evita a criação de várias classes pequenas de fábrica, no entanto acaba criando um código gigante para criação de objetos. Durante a implementação é necessário escolher qual tipo de implementação resolve melhor o seu problema.

88 Mediator

89  Problema Pense na seguinte situação: seria legal ter um aplicativo que trocasse mensagem entre diversas plataformas móveis, um Android enviando mensagem para um iOS, um Symbian trocando mensagens com um Android…

90 Mediator  Problema O problema é que cada uma destas plataforma implementa maneiras diferentes de receber mensagens. Obviamente seria uma péssima solução criar vários métodos para cada plataforma

91 Mediator

92 Imagine que agora o aplicativo vai incluir a plataforma BlackBerry OS, precisaríamos criar os métodos de comunicação com todas as outras plataforma existentes, além de adicionar métodos em todas as outras plataformas para que elas se comuniquem com o BlackBerry OS.

93 Mediator Esta ideia de relacionamento muitos para muitos pode deixar o design bem complexo, comprometendo a eficiência do sistema, bem como sua manutenibilidade.

94 Mediator Quando uma situação em que um relacionamento muitos para muitos é necessário em Banco de Dados, uma boa prática é criar uma tabela intermediária e deixar que ela relaciona uma entidade com outras várias e vice- e-versa. Esta é a ideia do padrão Mediator.

95 Padrões de Projeto Padrões de projetos : soluções reutilizáveis de software orinetado a objetos. Porto Alegre Bookman 2011. Recurso online ISBN 9788577800469. https://brizeno.wordpress.com/tag/composite/ https://brizeno.wordpress.com/tag/observer/ https://brizeno.wordpress.com/tag/strategy/ https://brizeno.wordpress.com/category/padroes-de-projeto/factory-method/ https://brizeno.wordpress.com/category/padroes-de-projeto/mediator/