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 Na aula passada...  Composite  Observer  Strategy  Factory Method  Mediator...

3 Mediator (Continuação)

4 Mediator “Definir um objeto que encapsula a forma como um conjunto de objetos interage. O Mediator promove o acoplamento fraco ao evitar que os objetos se refiram uns aos outros explicitamente e permitir variar suas interações independentemente.”

5 Mediator  O Mediator atua como um mediador entre relacionamentos muitos para muitos;  Outra vantagem é que ele concentra a maneira como os objetos interagem.

6 Mediator  O padrão Mediator consiste de duas figuras principais: o Mediator e o Colleague. O Mediator recebe mensagens de um Colleague, define qual protocolo utilizar e então envia a mensagem. O Colleague define como receberá uma mensagem e envia uma mensagem para um Mediator.

7 Mediator  Implementação do Colleague que servirá como base para todos os outros:

8 Mediator  Define apenas a interface comum de qualquer Colleague.  Todos possuem um Mediator, que deve ser compartilhado entre os objetos Colleague.  Também define a maneira como todos os objetos Colleague enviam mensagens.  O método “receberMensagem()” fica a cargo das subclasses.

9 Mediator  Como exemplo de Colleague, vejamos as classes a seguir, que representam as plataformas Android e iOS:

10 Mediator  Vejamos então como funciona o Mediator. Vamos primeiro definir a interface comum de qualquer Mediator:

11 Mediator  Ou seja, todo Mediator deverá definir uma maneira de enviar mensagens. Vejamos então como o Mediator concreto seria implementado:

12

13 Mediator  O Mediator possui uma lista de objetos Colleague que realizarão a comunicação e um método para adicionar um novo Colleague.  O método “enviar()” percorre toda a lista de contatos e envia mensagens.  Note que dentro deste métodos foi feita uma comparação para evitar a mensagem seja enviada para a pessoa que enviou.

14 Mediator  Para enviar a mensagem primeiro deve ser definido qual protocolo utilizar e em seguida enviar a mensagem.  No nosso exemplo, o método “definirProtocolo()” apenas imprime na tela o tipo do Colleague que enviou a mensagem, utilizar para isso a verificação instanceof.

15 Mediator  Desta maneira, o cliente poderia ser algo do tipo:

16 Mediator

17  O padrão Mediator tem como principal objetivo diminuir a complexidade de relacionamentos entre objetos, garantindo assim que todos fiquem mais livres para sofrer mudanças, bem como facilitando a introdução de novos tipos de objetos ao relacionamento.

18 Mediator  Outro ganho é a centralização da lógica de controle de comunicação entre os objetos, imagine que o protocolo de comunicação com o Android precisasse ser alterado, a mudança seria em um local bem específico da classe Mediator.

19 Façade Problema  No desenvolvimento de jogos é comum a utilização de subsistemas de um Framework/API.  Por exemplo, para reproduzir um determinado som é utilizado o subsistema de Audio, que normalmente provê funcionalidades desde a configuração da reprodução de audio, até a reprodução de um determinado arquivo.

20 Façade  Antes de iniciar o jogo de fato é necessário realizar ajustes em todos os subsistemas que serão utilizados, por exemplo, é necessário configurar a resolução do subsistema de Vídeo para que este possa renderizar imagens corretamente.

21 Façade

22  Ela fornece os métodos para configuração e reprodução de arquivos de áudio. Para reproduzir um arquivo de áudio, por exemplo, seria necessário realizar as seguintes operações:

23 Façade  Neste exemplo de código cliente, o próprio cliente deve instanciar e configurar o subsistema para que só depois seja possível a utilização dos mesmos. Além disso, existe um comportamento padrão que é executado antes de reproduzir um som: sempre deve ser configurado o canal, a frequência e o volume.

24 Façade  Agora pense como seria caso fosse necessário utilizar vários subsistemas? O código cliente ficaria muito sobrecarregado com responsabilidades que não são dele:

25 Façade  Como o padrão Facade pode resolver este pequeno problema.

26 Façade “Fornecer uma interface unificada para um conjunto de interfaces em um subsistema. Facade define uma interface de nível mais alto que torna o subsistema mais fácil de ser usado.”

27 Façade  De acordo com a descrição do padrão é possível notar que pode-se ajudar bastante na resolução do nosso problema. O conjunto de interfaces seria exatamente o conjunto de subsistemas. Um subsistema é análogo a uma classe, uma classe encapsula estados e operações, enquanto um subsistema encapsula classes.

28 Façade  Nesse sentido o Facade vai definir operações a serem realizadas com estes subsistemas. Assim, é possível definir uma operação padrão para configurar o subsistema de audio, evitando a necessidade de chamar os métodos de configuração de audio a cada novo arquivo de audio que precise ser reproduzido.

29 Façade  A utilização do padrão Facade é bem simples. apenas é necessário criar a classe fachada que irá se comunicar com os subsistemas no lugar no cliente:

30

31 Façade  A classe fachada realiza a inicialização de todos os subsistemas e oferece acesso aos métodos necessários, por exemplo o método de renderização de uma imagem, a reprodução de um audio.

32 Façade  Com esta mudança, tiramos toda a responsabilidade do cliente, que agora precisa se preocupar apenas em utilizar os subsistemas que desejar.

33 Façade  A utilização do padrão é bem simples e poder ser aplicado em várias situações.  A ideia básica do padrão, como visto, é remover a complexidade das classes clientes.

34 Façade  Visualmente falando, ele faz o seguinte:

35 Façade  Note que as classes do subsistema continuam sendo visíveis em todo o projeto.  Portanto, caso seja necessário, o cliente pode definir suas configurações sem sequer utilizar a classe fachada.  Ainda mais, o cliente pode criar uma fachada própria, que define suas operações customizadas. Por exemplo, se não serão utilizados joysticks no projeto, não há necessidade de inicializá-los.

36 Façade  O problema com essa centralização da complexidade é que a classe fachada pode crescer descontroladamente para abrigar uma conjunto grande de possibilidades. Nestes casos pode ser mais viável procurar outros padrões, como Abstract Factory para dividir as responsabilidades entre subclasses.

37 Façade  Uma semelhança que também pode ser notada é com o padrão Mediator, já que ambos reduzem a complexidade entre um grande conjunto de objetos.  A diferença é que como o padrão Mediator centraliza a comunicação entre os objetos colegas, normalmente adicionando novas funcionalidades e sendo referenciado por todos os colegas.  No padrão Facade, a classe fachada apenas utiliza os subsistemas, sem adicionar nada, além disso as classes do subsistema não sabem nada sobre a fachada.

38 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/