Classificação: Comportamental Evita acoplar o remetente de uma requisição ao seu destinatário...

Post on 16-Apr-2015

109 views 0 download

Transcript of Classificação: Comportamental Evita acoplar o remetente de uma requisição ao seu destinatário...

Classificação: Comportamental Evita acoplar o remetente de uma requisição ao seu destinatário ao dar a mais de um objeto a chance de servir a requisição. Compõe os objetos em cascata e passa a requisição pela corrente até que um objeto a sirva

Professor: Ângelo de Moura GuimarãesTutor: Guilherme MansoAluno: Anderson Giovani

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 [Silva, 2005]. 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 [Allen & Bambara, 2003].

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 [Metsker, 2004].

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 [Silva, 2005]. 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.

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.

No Chain of Responsability, ilustrado na Figura 1, um modelo de objetos assume a tarefa de descobrir qual objeto pode satisfazer sua solicitação.

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. Requisição : As instâncias de Requisição é que iram transportar as informações para os alimentadores executarem algo.

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.

No exemplo ilustrado na Figura 2, a implementação é relacionada a uma máquina de refrigerantes, na qual vai-se adicionando moedas até o valor do refrigerante ser alcançado para a sua aquisição.

As classes contidas dentro do pacote “moedas” são os AlimentadoresConcretos, enquando Moeda é a requisição enviada.

Como existem infinitos tipos de moedas, pois é possível encontrar moedas tanto as que estão em circulação em nosso país, como as que estão em circulação nas mais de outras duzentas nações, além das moedas que já são antigas e não possui mais validade monetária, a máquina de refrigerantes tem que descobrir qual moeda entrou através de possíveis padrões, como por exemplo, a espessura, raio e peso. Neste exemplo, a cada moeda que entra - a cada requisição - uma classe alimentadora analisa a moeda e busca ver se está dentro dos seus padrões, caso não esteja, vai passar para alguma outra classe alimentadora até que seja descoberta qual moeda entrou. Caso não se encaixe em nenhuma das especificações, a moeda será descartada e não será computado valor algum.

Chain of Responsibility pode ser implementada com estratégias que permitem maior ou menor acoplamento entre os participantes

•Usando um mediador: só o mediador sabe quem é o próximo participante da cadeia

•Usando delegação: cada participante conhece o seu sucessor

Este padrão de primeira vista parece simples, o que na realidade não deixa de ser, no entanto, inicialmente ele causa indagações com relação a sua real utilidade, não chega-se a perceber no primeiro olhar que ele é um padrão importante e útil. É difícil imaginar cenários aplicáveis a ele, o que dificulta sua implementação.

http://www.argonavis.com.br/cursos/java/j930/index.htmlAcesso em 3 /10/2009http://www.pg.cefetpr.br/coinf/simone/patterns/chain.php Acesso em 3/10/2009