Design Patterns
Elizabeth Suescún Monsalve
Padrão Chain of Responsibility
(cadeia de responsabilidades)
Padrão Chain of Responsibility
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.
© LES/PUC-Rio
Padrão Chain of Responsibility
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.
© LES/PUC-Rio
Padrão Chain of Responsibility
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.
© LES/PUC-Rio
Padrão Chain of Responsibility
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
© LES/PUC-Rio
Padrão Chain of Responsibility
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.
© LES/PUC-Rio
Padrão Chain of Responsibility
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.
© LES/PUC-Rio
Padrão Chain of Responsibility
Estrutura
© LES/PUC-Rio
Padrão Chain of Responsibility
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.
© LES/PUC-Rio
Padrão Chain of Responsibility
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.
© LES/PUC-Rio
Padrão Chain of Responsibility
Conseqüências
• Vantagens e inconvenientes do padrão:
– Reduz o acoplamento.
– Adiciona flexibilidade para designar responsabilidades aos
objetos.
– Não é garantida a recepção.
© 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
Padrão Chain of Responsibility
© LES/PUC-Rio
Padrão Chain of Responsibility
© LES/PUC-Rio
Fim!!