Design Patterns Elizabeth Suescún Monsalve. Padrão Chain of Responsibility (cadeia de...
Transcript of Design Patterns Elizabeth Suescún Monsalve. Padrão Chain of Responsibility (cadeia de...
Design Patterns
Elizabeth Suescún Monsalve
Padrão Chain of Responsibility (cadeia de responsabilidades)
© LES/PUC-Rio
Propósito do Padrão
• O padrão “Chain of Responsability” evita acoplar o emissor de uma petição com seu receptor, dando para mais de um objeto a possibilidade de responder à petição. Encadeia os objetos receptores e passa a petição a traves da cadeia hasta que é processada por algum objeto.
Padrão Chain of Responsibility
© LES/PUC-Rio
Motivação
• Exemplo
O caso que temos é um gerador de logs. O sistema detecta um evento do qual deve informar, mais o sistema não precisa de se preocupar da classificação da mensagem e sua impressão, então, somente vai limitar-se a informar. Alem disso, necessita-se de uma forma de desacoplar o emissor e o sistema dos possíveis receptores, ou seja, os geradores de logs.
Padrão Chain of Responsibility
© LES/PUC-Rio
Motivação
• Contexto do exemplo
– O primeiro objeto da cadeia recebe a petição, o qual pode processar ou enviá-la ao seguinte objeto da cadeia que vai fazer exatamente o mesmo.
– O objeto que fez a petição não conhece qual dos objetos da cadeia vai responder a sua petição.
– Se diz então que a petição tem receptor implícito.
Padrão Chain of Responsibility
© LES/PUC-Rio
Motivação
• Suponha que o sistema há enviado um e-mail, o gerador de logs do e-mail se encontra em uma instancia do EmailLogger. O diagrama ilustra como a petição de imprimir a entrada de log passa a traves da cadeia
Padrão Chain of Responsibility
© LES/PUC-Rio
Motivação
• Neste caso a petição não é processada pelo DebuggerLogger, e é detida no EmailLogger, o qual pode processá-la ou obviá-la. O cliente que deu origem à petição não fica sabendo qual é o objeto que finalmente trata a petição.
• Para garantir a petição ao longo da cadeia e para garantir que os receptores permaneçam implícitos, cada objeto da cadeia compartilha uma interface comum para processar as petições e para acessar ao seu sucessor na cadeia. Em nosso caso o método mensagem controla as petições.
Padrão Chain of Responsibility
© LES/PUC-Rio
Aplicabilidade
• Este padrão deve ser usado quando:
– Quando tem-se mais de um objeto que pode controlar uma petição e essa petição não se conhece a - priori, deve-se determinar automaticamente.
– Se deseja enviar uma petição para um objeto entre vários sem especificar explicitamente o receptor.
– O conjunto de objetos que podem tratar uma petição deve ser especificado dinamicamente.
Padrão Chain of Responsibility
© LES/PUC-Rio
Estrutura
Padrão Chain of Responsibility
© LES/PUC-Rio
Participantes
• Handler (Comunicador):
– Define uma interface para tratar as petições.
– Implementa o enlace ao sucessor.
• ConcreteHandler (DebugLogger, EmailLogger)
– Trata as petições das quais é responsável.
– Pode aceder ao seu sucessor.
– Se o ConcreteHandler pode manejar a petição ele faz, senão o reenvia ao seu sucessor.
• Client:
– Inicializa a petição para um objeto ConcreteHandler da cadeia.
Padrão Chain of Responsibility
© LES/PUC-Rio
Colaborações
• Quando um Client envia uma petição, esta se propaga a traves da cadeia hasta que um objeto ConcreteHandler se faz responsável de processá-la.
Padrão Chain of Responsibility
© LES/PUC-Rio
Conseqüências
• Vantagens e inconvenientes do padrão:
– Reduz o acoplamento.
– Adiciona flexibilidade para designar responsabilidades aos objetos.
– Não é garantida a recepção.
Padrão Chain of Responsibility
© LES/PUC-Rio
Padrão Chain of Responsibility
Padrão Chain of Responsibility
© LES/PUC-Rio
Padrão Chain of Responsibility
© LES/PUC-Rio
Padrão Chain of Responsibility
© LES/PUC-Rio
Padrão Chain of Responsibility
© LES/PUC-Rio
Padrão Chain of Responsibility
© LES/PUC-Rio
Padrão Chain of Responsibility
© LES/PUC-Rio
Fim!!