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!!