Especialização em web com interfaces ricas

Transcrição

1 Especialização em web com interfaces ricas Padrões de Projeto - Comportamentais Prof. Fabrízzio Alphonsus A. M. N. Soares fabrizzio@inf.ufg.br professor.fabrizzio@gmail.com Instituto de Informática Universidade Federal de Goiás Aula 9 25 de maio de 2012 Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 1/112

2 Padrões de Projeto - Comportamentais I São os padrões que estão preocupados com os algoritmos e as atribuições de responsabilidade entre objetos. Descrevem não só os padrões entre objetos ou classes, mas também os padrões de comunicação entre eles. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 2/112

3 Padrões de Projeto - Comportamentais II Estes padrões caracterizam um complexo fluxo de controle que é difícil de seguir em tempo de execução. Eles transportam sua atenção para longe do fluxo de controle e lhe permite concentrarse apenas no modo como os objetos estão interconectados. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 3/112

4 Padrões de Projeto - Comportamentais III Lista de padrões comportamentais Chain of responsability Mediator Strategy Command Memento Template Method Interpreter Observer Visitor Iterator State Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 4/112

5 Chain of responsability I O padrão de projeto de software Chain of Responsibility representa um encadeamento de objetos receptores para o processamento de uma série de solicitações diferentes. Esses objetos receptores passam a solicitação ao longo da cadeia até que um ou vários objetos a tratem. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 5/112

6 Chain of responsability II Cada objeto receptor possui uma lógica descrevendo os tipos de solicitação que é capaz de processar e como passar adiante aquelas que requeiram processamento por outros receptores. A delegação das solicitações pode formar uma árvore de recursão, com um mecanismo especial para inserção de novos receptores no final da cadeia existente. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 6/112

7 Chain of responsability III Dessa forma, fornece um acoplamento mais fraco por evitar a associação explícita do remetente de uma solicitação ao seu receptor e dar a mais de um objeto a oportunidade de tratar a solicitação. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 7/112

8 Chain of responsability IV Um exemplo da aplicação desse padrão é o mecanismo de herança nas linguagens orientadas a objeto: um método chamado em um objeto é buscado na classe que implementa o objeto e, se não encontrado, na superclasse dessa classe, de maneira recursiva. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 8/112

9 Propósito I Não conhecer de antemão qual objeto irá responder a uma determinada requisição. Compor os objetos em cascata e passar a requisição pela corrente até que um objeto a sirva. Evitar a união entre o remetente de uma solicitação e seu receptor, dando aos diversos objetos uma chance de tratar da solicitação Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 9/112

10 Motivação I Em projetos orientados a objetos manter os objetos com acoplamento fraco, mantendo específica e mínima a responsabilidade entre eles, faz com que mudanças sejam inseridas com menos risco de falhas. Os clientes apenas enxergam a interface visível do objeto permanecerem isolados de detalhes de implementação Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 10/112

11 Motivação II Uma máquina de refrigerantes necessita armazenar em locais diferentes cada tipo de moeda possível. Pode ser útil que um objeto receba a moeda, mas se ele não for capaz de armazenar no local correto, passe-o para outro objeto buscando a colocação correta da moeda. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 11/112

12 Motivação III Isso é um exemplo de tentativa de desacoplamento, já que se alguém não pode resolver determinada tarefa ocorre uma delegação da responsabilidade para outro objeto de forma totalmente transparente. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 12/112

13 Aplicabilidade I Mais de um objeto pode tratar de uma solicitação e este é desconhecido. Uma solicitação deve ser emitida para um entre os vários objetos e o receptor, não sendo especificado explicitamente. O conjunto de objetos capaz de tratar da solicitação deve ser especificado dinamicamente. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 13/112

14 Estrutura I Participantes Alimentador define a interface para tratar as solicitações e implementa a referência ao sucessor (opcional). AlimentadorConcretoA,..., AlimentadorConcretoN trata as solicitações pelas quais é responsável. Pode acessar seu sucessor. Se o AlimentadorConcreto pode tratar a solicitação, ele assim o faz; caso contrário ele repassa a solicitação para o seu sucessor. Cliente Inicia a solicitação para um objeto AlimentadorConcreto da cadeia. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 14/112

15 Estrutura II Requisição As instâncias de Requisição é que iram transportar as informações para os alimentadores executarem algo. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 15/112

16 Estrutura III Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 16/112

17 Vantagens I Evita acoplamento do transmissor de um requisição com seus receptores, fazendo com que mais de um projeto tenha a chance de manipular a requisição. Encadeia os objetos receptores e passa a requisição ao longo dessa cadeia até que um objeto possa manipulá-lo. Reduz a vinculação. Adiciona flexibilidade. Permite que um conjunto de classes atue como uma classe; eventos produzidos em uma classe podem ser enviados para outras classes dentro da composição. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 17/112

18 Implementação I Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 18/112

19 Padrão Command I Encapsular uma solicitação como um objeto, desta forma permitindo que clientes parametrizem diferentes solicitações, enfileirem ou façam o registro (log) de solicitações e suportem operações que podem ser desfeitas. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 19/112

20 Padrão Command II Encapsular uma solicitação como um objeto, permitindo desta forma parametrizar clientes com diferentes solicitações, enfileirar ou fazer o registro (log) de solicitações e suportar operações que podem ser desfeitas. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 20/112

21 Padrão Command III Também conhecido como: Action, Transaction. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 21/112

22 Problema I Algumas vezes é necessário emitir solicitações para objetos nada sabendo sobre a operação que está sendo solicitada ou sobre o receptor da mesma. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 22/112

23 Motivação I Algumas vezes é necessário emitir solicitações para objetos que nada sabem sobre a operação que está sendo solicitada ou sobre o receptor da mesma. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 23/112

24 Motivação II Exemplo: toolkits para construção de interfaces de usuário incluem objetos como botões de menus que executam uma solicitação em resposta à entrada do usuário. Mas, o toolkit não pode implementar a solicitação explicitamente no botão ou no menu porque somente as aplicações que utilizam o toolkit sabem o que deveria ser feito e em qual objeto. Como projetistas de toolkits, não temos meios de saber qual é o receptor da solicitação ou as operações que ele executará. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 24/112

25 Motivação III O padrão Command permite a objetos de toolkit fazer solicitações de objetos-aplicação não especificados, transformando a própria solicitação em um objeto. Este objeto pode ser armazenado e passado como outros objetos. A interface Command: Define uma interface para execução de operações. Na sua forma mais simples, inclui uma única operação execute(). Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 25/112

26 Utilizar quando? I Utilizar quando: Parametrizar objetos por uma ação a ser executada. Você pode expressar tal parametrização numa linguagem procedural através de uma função callback, ou seja, uma função que é registrada em algum lugar para ser chamada em um momento mais adiante. Os Commands são uma substituição orientada a objetos para callbacks; Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 26/112

27 Utilizar quando? II Especificar, enfileirar e executar solicitações em tempos diferentes. Um objeto Command pode ter um tempo de vida independente da solicitação original. Se o receptor de uma solicitação pode ser representado de uma maneira independente do espaço de endereçamento, então você pode transferir um objeto Command para a solicitação para um processo diferente e lá atender a solicitação; Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 27/112

28 Utilizar quando? III Suportar desfazer operações. A operação Execute, de Command, pode armazenar estados para reverter seus efeitos no próprio comando. A interface do Command deve ter acrescentada uma operação Unexecute, que o reverte.efeitos de uma chamada anterior de Execute. Os comandos executados são armazenados em uma lista histórica. O nível ilimitado de desfazer e refazer operações é obtido percorrendo esta lista para trás e para frente, chamando operações Unexecute e Execute, respectivamente. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 28/112

29 Aplicação I A chave deste padrão é uma classe abstrata Command, a qual declara uma interface para execução de operações. Na sua forma mais simples, esta interface inclui uma operação abstrata Execute. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 29/112

30 Aplicação II As subclasses concretas de Command especificam um par receptoração através do armazenamento do receptor como uma variável de instância e pela implementação de Execute para invocar a solicitação. O receptor tem o conhecimento necessário para poder executar a solicitação. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 30/112

31 Estrutura I Participantes: Command Declara uma interface para a execução de uma operação. ConcreteCommand Define uma vinculação entre um objeto Receiver e uma ação. Implementa execute() através da invocação da(s) correspondente(s) operação(ções) no Receiver. Client Cria um objeto ConcreteCommand e estabelece o seu receptor (Receiver). Invoker Solicita ao Command a execução da solicitação. Receiver Sabe como executar as operações associadas a uma solicitação. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 31/112

32 Estrutura II Qualquer classe pode funcionar como um Receiver. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 32/112

33 Estrutura III Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 33/112

34 Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 34/112

35 Consequencias I Command desacopla o objeto que invoca a operação daquele que sabe como executá-la. Commands são objetos de primeira classe, ou seja, podem ser manipulados e estendidos como qualquer outro objeto. Um comando pode ser composto por outros comandos. Um exemplo disso é a classe MacroCommand descrita anteriormente. Em geral, comandos compostos são uma instância do padrão Composite. É fácil acrescentar novos Commands porque não é preciso mudar classes existentes. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 35/112

36 Padrão interpreter I Interpreter é um padrão de projeto de software que especifica como entender frases em uma determinada linguagem de programação. O padrão de projeto Interpreter pode ser utilizado para representar e resolver problemas recorrentes que possam ser expressos sob a forma de uma linguagem formal simples. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 36/112

37 Padrão interpreter II É usado para ajudar uma aplicação a entender uma declaração de linguagem natural e executar a funcionalidade da declaração. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 37/112

38 Propósito I Dada uma linguagem, cria uma representação para a gramática da linguagem, juntamente com um interpretador que usa esta representação para interpretar sentenças na linguagem. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 38/112

39 Motivação I O padrão Interpreter pode ser utilizado para representar e resolver problemas recorrentes que possam ser expressos sob a forma de uma linguagem formal simples. O padrão Interpreter usa classes para representar cada regra de uma gramática (expressão regular). Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 39/112

40 Consequencias I Vantagem: Flexibilidade Desvantagem: Velocidade e Complexidade Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 40/112

41 Padrão iterator I Fornecer uma maneira de acessar seqüencialmente os elementos de um objeto agregado sem expor sua implementação Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 41/112

42 Motivação I Padrão Iterator retira a responsabilidade de acesso e percurso do objeto, listando e colocando em um objeto iterator. Permite percorrer a lista de diferentes maneiras Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 42/112

43 Aplicabilidade I O acesso a um objeto da coleção é requerido sem precisar expor sua representação interna. Diversas travessias de objetos devem ser suportadas na coleção. Uma interface universal para percorrer diferentes estruturas precisa ser fornecida na coleção. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 43/112

44 Estrutura I Participantes IteradorIF define a interface para acessar e percorrer os elementos IteradorConcreto Implementa a interface Iterator; Mantém o controle da posição corrente no percurso do agregado. ColecaoIF define uma interface para a criação de um objeto Iterator. ColecaoConcreta implementa a interface de criação do Iterador para retornar uma instância do ConcreteIterador. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 44/112

45 Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 45/112

46 Vantagem I Suporta variações na travessia, ou percurso, de uma coleção. Simplifica a interface para a coleção. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 45/112

47 Iterador em java I Abaixo seguem alguns códigos que exemplificam a navegação em coleções com e sem o uso de iteradores. 1 for ( int i = 0 ; i < MAXIMO ; i++ ){ 2 // trabalha com i 3 } 1 Object [] array = new Object [ 10 ] 2 for ( int i = 0 ; i < array.length ; i++ ){ 3 Object obj = array [ i ] ; 4 // trabalha com obj 5 } Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 46/112

48 Iterador em java II 1 ObjectGroup groupofobjects = new ObjectGroup () ; 2 Iterator it = Iterator.iteratorFor ( groupofobjects ) ; 3 4 while ( it.hasmore () ){ 5 Object obj = it.current () ; 6 // trabalha com obj 7 } Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 47/112

49 Padrão Mediator I Um mediador é quem desacopla e gerencia as colaborações entre um grupo de objetos. Define um objeto que encapsula as interações dentre desse grupo. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 48/112

50 Padrão Mediator II Normalmente, um programa é feito por um número muito grande de classes. Então, a lógica e o código são distribuídos entre essas classes. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 49/112

51 Padrão Mediator III No entanto, quanto mais classes houver no seu projeto, a comunicação entre essas classes será mais complexa. Isso faz com que a leitura e a manutenção do programa fique mais difícil, tal situação acarreta na dificuldade de mudanças no projeto, já que, uma simples mudança pode afetar todo o código e as outras classes. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 50/112

52 Padrão Mediator IV Com o padrão mediator, a comunicação entre os objetos é encapsulada com um objeto mediador. Isso reduz a dependência entre os objetos que estão se comunicando. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 51/112

53 Definição I Define um objeto que encapsula como um conjunto de objetos interage. O padrão Mediator promove um baixo acoplamento evitando que os objetos façam referência uns aos outros de forma explícita, permitindo a você variar o uso da interação de forma independente. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 52/112

54 O problema I Como permitir que um grupo de objetos se comunique entre si sem que haja acoplamento entre eles? Como remover o forte acoplamento presente em relacionamentos muitos para muitos? Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 53/112

55 Solução I Introduzir um mediator: objetos podem se comunicar sem se conhecer. Um objeto Mediador deve encapsular toda a comunicação entre um grupo de objetos Cada objeto participante conhece o mediador, mas ignora a existência dos outros objetos; O mediador conhece cada um dos objetos participantes; A interface do Mediador é usada para iniciar a comunicação e receber notificações O mediador recebe requisições dos remetentes; O mediador repassa as requisições aos destinatários. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 54/112

56 Checklist I 1 Identificar uma coleção de objetos que interagem e que se beneficiariam com o desacoplamento mútuo; 2 Encapsular essas interações na abstração de uma nova classe; 3 Criar uma instância dessa nova classe e refazer todos os colegas de objetos para interagir com um único Mediador; 4 Equilibrar o princípio do desacoplamento com o princípio da distribuição de responsabilidade de maneira uniforme; 5 Tomar cuidado para criar um Controlador ou um objeto deus. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 55/112

57 Estrutura I Participantes Mediator define uma interface para comunicação com os objetos Colleague; ConcreteMediator conhece as classes Colleague e mantém uma referência aos objetos Colleague. Ele implementa a comunicação e a transferência de mensagens entre as classes Colleague; Classes Colleague mantêm uma referência ao seu objeto Mediator - se comunicam com o Mediator sempre que necessário. De outra forma, se comunicam com um Colleague. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 56/112

58 Estrutura II Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 57/112

59 Vantagens I Desacoplamento entre os diversos participantes da rede de comunicação (participantes não se conhecem); Eliminação de relacionamentos muitos para muitos (são todos substituídos por relacionamentos um para muitos); A política de comunicações está centralizada no mediador e pode ser alterada sem mexer nos colaboradores. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 58/112

60 Desvantagens I A centralização pode ser uma fonte de gargalos de desempenho e de risco para o sistema em caso de falha; Na prática, os mediadores tendem a se tornar mais complexos. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 59/112

61 Padrões relacionados I Facade Um mediator simplificado torna-se um padrão Facade se o mediador for a única classe ativa e se as classes Colleagues forem classes passivas; Adapter O padrão Mediator apenas media os pedidos entre as classes Colleague; Observer Os padrões Mediator e Observer são semelhantes, resolvendo o mesmo problema. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 60/112

62 Padrão Memento I Memento é um padrão de projeto que permite armazenar o estado interno de um objeto em um determinado momento, para que seja possível retorná-lo a este estado, caso necessário. Conhecido como Token. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 61/112

63 Propósito I Captar e externalizar um estado interno de um objeto, de maneira que esse estado seja restaurado ao objeto em outro momento, sem violar seu encapsulamento. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 62/112

64 Motivação I Em programas de computador, nem sempre uma seqüência linear e contínua de ações satisfaz as necessidades que um aplicativo deve atender - principalmente quando se trata de contato direto com o usuário: ações como desfazer e voltar se fazem necessárias. Ainda, quando uma determinada situação desejada é obtida no sistema, é comum o desejo do usuário de armazenar resultados para usos posteriores. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 63/112

65 Motivação II Com este objetivo, se apresenta o padrão Memento com a finalidade de criar um repositório de informações sobre um objeto, que pode ser acessado tanto para guardar como para recuperar essas informações, que representam um estado de um objeto específico. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 64/112

66 Motivação III A maneira mais comum de guardar informações dessa maneira é através de um clone do objeto, instanciado com as informações do estado a ser guardado. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 65/112

67 Motivação IV Deste modo, não haverá exposição direta do estado interno do objeto, ou seja, não será violado o seu encapsulamento. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 66/112

68 Aplicabilidade I Na implementação de ações de desfazer ; Para o armazenamento de estados a serem restaurados de um objeto, como por exemplo, um banco de dados; Para a captação de estados de objetos que são encobertos por encapsulamento; Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 67/112

69 Estrutura I Participantes Objeto é o objeto que vai oferecer algum estado para ser guardado, possivelmente restaurado num momento posterior. Seus estados só podem ser acessados por seus métodos (ou seja, o encapsulamento é preservado). Memento guarda e recupera estados do objeto especificado. Cliente cria e faz uso de um objeto Memento, instanciando-o e solicitando a este que guarde ou restaure um estado de uma instância de Objeto. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 68/112

70 Estrutura II Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 69/112

71 Padrão Observer I O Observer é um padrão de projeto de software que define uma dependência um-para-muitos entre objetos de modo que quando um objeto muda o estado, todos seus dependentes sejam notificados e atualizados automaticamente. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 70/112

72 Padrão Observer II Permite que objetos interessados sejam avisados da mudança de estado ou outros eventos ocorrendo num outro objeto. O padrão Observer é também chamado de Publisher-Subscriber, Event Generator e Dependents. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 71/112

73 Motivação I Um objeto que possua agregações deve permitir que seus elementos sejam acessados sem que a sua estrutura interna seja exposta. De uma maneira geral pode-se desejar que estes elementos sejam percorridos em várias ordens. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 72/112

74 Motivação II Como garantir que objetos que dependem de outro objeto percebam as mudanças naquele objeto? Os observadores (observer) devem conhecer o objeto de interesse. O objeto de interesse (subject) deve notificar os observadores quando for atualizado. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 73/112

75 Motivação III Os objetos devem-se interligar entre si de forma a que não se conheçam em tempo de compilação de forma a criar o acoplamento e desfazê-lo a qualquer momento em tempo de execução. Solucionar isso fornece uma implementação muito flexível de acoplamento de abstrações. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 74/112

76 Aplicabilidade I O padrão Observer pode ser usado quando uma abstração tem dois aspectos, um dependente do outro. Encapsular tais aspectos em objetos separados permite que variem e sejam reusados separadamente. Quando uma mudança a um objeto requer mudanças a outros e você não sabe quantos outros objetos devem mudar ou quando um objeto deve ser capaz de avisar outros sem fazer suposições sobre quem são os objetos. Em outras palavras, sem criar um acoplamento forte entre os objetos. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 75/112

77 Padrão State I State é um padrão de projeto de software usado para permitir que um objecto altere o seu comportamento quando o seu estado muda. Ao utilizar este padrão, parecerá que o objeto mudou de classe. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 76/112

78 Padrão State II O padrão State deve ser utilizado nas seguintes situações: O comportamento de um objeto depende fortemente do seu estado e ele deve alterar o seu comportamento em tempo de execução dependendo do estado. Os métodos têm instruções condicionais grandes em que as condições dependem do estado do objecto. Este estado é normalmente representado por uma ou mais constantes do tipo enumerado. Frequentemente, vários métodos contém esta mesma estrutura condicional. O padrão State coloca cada ramo da instrução condicional numa classe separada. Desta forma, o estado do objeto pode ser tratado como um objecto ele próprio, o qual pode variar. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 77/112

79 Propósito I Permitir que um objeto altere seu comportamento se seu estado interno for alterado, parecendo como se o próprio objeto tivesse alterado sua classe. Distribuir lógica específica de estado mediante classes que representem o estado de um objeto. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 78/112

80 Motivação I O estado de um objeto é uma combinação dos valores atuais dos seus atributos. Quando chamado um método set, tipicamente muda-se o estado do objeto, e este pode mudar o seu próprio estado enquanto seus métodos são executados. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 79/112

81 Motivação II Em alguns casos, o estado de um objeto pode ser um aspecto proeminente do seu comportamento. A lógica que depende desse estado pode espalhar-se por meio de muitos dos métodos da classe. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 80/112

82 Motivação III Para evitar esse espalhamento, pode-se mover o comportamento específico de estado para dentro de um grupo de classes, com cada uma representando um estado diferente. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 81/112

83 Aplicabilidade I Quando uma classe define muitos comportamentos Quando classes relacionadas forem diferentes apenas no seu comportamento Quando você precisar de diferentes variações de um mesmo algoritmo Múltiplas classes diferem somente quanto aos seus comportamentos. A servlet API é um exemplo clássico disso. Um algoritmo utiliza dados que não são conhecidos ao cliente. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 82/112

84 Estrutura I Ao modelar um objeto cujo estado é importante, pode-se descobrir que há uma variável que monitora o modo como esse objeto deveria se comportar, dependendo do seu estado. Essa variável pode aparecer em comandos if complexos, em cascata, que focalizam como reagir aos eventos que o objeto pode experimentar. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 83/112

85 Estrutura II Participantes Contexto Define a interface de interesse para os clientes. Mantém uma instância de uma subclasse EstadoConcreto que define o estado corrente Estado Define uma interface para encapsular o comportamento associado com um estado particular do contexto EstadoConcreto Implementa um comportamento associado a um estado do Contexto. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 84/112

86 Estrutura III Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 85/112

87 Consequencias I Mantém local o comportamento específico de estado e o comportamento das partições em diferentes estados. Torna explícitas quaisquer transições de estado. Evita profundos ou complexos comandos if, dependendo, então, do polimorfismo para executar a correta implementação de uma operação. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 86/112

88 Padrão Strategy I O objetivo é representar uma operação a ser realizada sobre os elementos de uma estrutura de objetos. O padrão Strategy permite definir novas operações sem alterar as classes dos elementos sobre os quais opera. Definir uma família de algoritmos e encapsular cada algoritmo como uma classe, permitindo assim que elas possam ter trocados entre si. Este padrão permite que o algoritmo possa variar independentemente dos clientes que o utilizam. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 87/112

89 Propósito I Definir uma família de algoritmos, encapsular cada um, e fazê-los intercambiáveis Strategy permite que algoritmos variem independentemente entre clientes que os utilizam Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 88/112

90 Motivação I Quando se necessita de um algoritmo que trata de modos diferentes os dados submetidos a ele. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 89/112

91 Aplicabilidade I Quando uma classe define muitos comportamentos Quando classes relacionadas forem diferentes apenas no seu comportamento Quando você precisar de diferentes variações de um mesmo algoritmo Múltiplas classes diferem somente quanto aos seus comportamentos. A servlet API é um exemplo clássico disso. Um algoritmo utiliza dados que não são conhecidos ao cliente. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 90/112

92 Estrutura I Participantes Estrategia define uma interface comum para todos os algoritmos suportados. EstrategiaConcreta1 e EstrategiaConcreta2 implementa o algoritmo usando a interface de Estratégia. Contexto É configurado com um objeto EstrategiaConcreta. Mantém uma referência para um objeto EstrategiaConcreta. Pode definir uma interface que permite a Estrategia acessar seus dados. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 91/112

93 Estrutura II Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 92/112

94 Consequencias I Vantagens Famílias de algoritmos relacionados; Uma alternativa ao uso de subclasses; Eliminam comandos condicionais; Desvantagens Aumento do número de objetos. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 93/112

95 Padrão Template Method I Um Template Method auxilia na definição de um algoritmo com partes do mesmo definidos por Método abstratos. As subclasses devem se responsabilizar por estas partes abstratas, deste algoritmo, que serão implementadas, possivelmente de várias formas, ou seja, cada subclasse irá implementar à sua necessidade e oferecer um comportamento concreto construindo todo o algoritmo. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 94/112

96 Padrão Template Method II O Template Method fornece uma estrutura fixa, de um algoritmo, esta parte fixa deve estar presente na superclasse, sendo obrigatório uma classeabstrata que possa conter um método concreto, pois em uma interface só é possível conter métodos abstratos que definem um comportamento, esta é a vantagem de ser uma Classe Abstrata porque também irá fornecer métodos abstratos às suas subclasses, que por sua vez herdam este método, por Herança (programação), e devem implementar os métodos abstratos fornecendo um comportamento concreto aos métodos que foram definidos como abstratos. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 95/112

97 Padrão Template Method III Com isso certas partes, do algoritmo, serão preenchidos por implementações que irão variar, ou seja, implementar um algoritmo em um método, postergando a definição de alguns passos do algoritmo, para que outras classes possam redefiní-los. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 96/112

98 Estrutura I Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 97/112

99 Padrão visitor I Representa uma operação a ser realizada sobre elementos da estrutura de um objeto. O Visitor permite que se crie um nova operação sem que se mude a classe dos elementos sobre as quais ela opera. É uma maneira de separar um algoritmo da estrutura de um objeto. Um resultado prático é a habilidade de adicionar novas funcionalidades a estruturas de um objeto pré-existente sem a necessidade de modificá-las. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 98/112

100 Padrão visitor II A idéia é usar uma classe de elementos como uma estrutura, sendo que cada uma delas possui um método cujo um dos argumentos é um objeto do tipo visitor. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 99/112

101 Padrão visitor III Visitor é uma interface que possui um método visit() para cada classe de elementos. O método accept() de uma classe de elementos invoca o método visit() de sua respectiva classe. Classes visitor concretas distintas podem então ser escritas para implementar operações especiais. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 100/112

102 Padrão visitor IV O padrão Visitor é uma solução para separar o algoritmo da estrutura. Uma das vantagens desse padrão é a habilidade de adicionar novas operações a uma estrutura já existente. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 101/112

103 Padrão visitor V Com ele, podemos ter a classe ObjetoSolido e o comportamento de queda em uma classe Gravidade, separada da estrutura do ObjetoSolido. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 102/112

104 Padrão visitor VI Isso é feito através de uma interface, onde o objeto que vai executar esse método da classe do comportamento, passa uma referencia dela mesmo junto dos parâmetros normais da classe. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 103/112

105 Padrão visitor VII Representa um método a ser executado sobre os elementos de uma estrutura de objetos. O padrão Visitor permite que se defina um novo método sem alterar as classes dos elementos sobre os quais o método age. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 104/112

106 Padrão visitor VIII Visitor promove a extensão de funcionalidades através da criação de classes que obedeçam a uma interface comum. Esta interface, Visitor (Visitante), especifica sobre que objetos os métodos poderão ser executados, definindo um método visitar(objetox o) para cada ObjetoX possível. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 105/112

107 Padrão visitor IX Os métodos são codificadas então em classes que implementam Visitante, o que permite que se crie novos métodos, mas não permite que se altere os objetos sobre os quais operam. Os objectos clientes criam o visitante que quiserem e chamam o método visitar() para o objecto sobre o qual pretendam operar. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 106/112

108 Estrutura I Participantes Visitor Visitor o Declara o método visit para cada classe de ConcreteElement na estrutura de objectos. O nome do método e a assinatura, identificam a classe que envia o pedido visit ao Visitor Isso permite ao visitor determinar a classe concreta do elemento a ser visitado. Então o visitor pode aceder directamente aos elementos, através da sua interface particular. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 107/112

109 Estrutura II ConcreteVisitor Implementa os métodos declarados pelo Visitor. Cada método implementa um fragmento do algoritmo definido para a correspondente classe ou objecto na estrutura. ConcreteVisitor fornece o contexto para o algoritmo e armazena o seu estado local. Este estado, geralmente acumula resultados durante a passagem pelos elementos da estrutura. Element Define o método Accept que recebe um visitor como argumento. ConcreteElement Implementa o método Accept que recebe um visitor como argumento. ObjectStructure Pode enumerar os seus elementos Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 108/112

110 Estrutura III Pode fornecer uma interface de alto-nível, para permitir o visitor visitar os seus elementos. Pode ser um padrão Composite ou uma collection - list ou set. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 109/112

111 Estrutura IV Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 110/112

112 Relacionamento entre os padrões do GoF I Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 111/112

113 Outros padrões I Booch coletou uma série de padrões, além dos previstos pelo GoF e pelo Grasp. Eles podem ser vistos no link: jacques/cursos/map/recursos/patterns.html Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 112/112