A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

Elizabeth Suescún Monsalve

Apresentações semelhantes


Apresentação em tema: "Elizabeth Suescún Monsalve"— Transcrição da apresentação:

1 Elizabeth Suescún Monsalve
Design Patterns Elizabeth Suescún Monsalve

2 Padrão Chain of Responsibility (cadeia de responsabilidades)

3 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

4 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

5 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

6 Padrão Chain of Responsibility
Motivação Suponha que o sistema há enviado um , o gerador de logs do se encontra em uma instancia do Logger. O diagrama ilustra como a petição de imprimir a entrada de log passa a traves da cadeia © LES/PUC-Rio

7 Padrão Chain of Responsibility
Motivação Neste caso a petição não é processada pelo DebuggerLogger, e é detida no Logger, 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

8 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

9 Padrão Chain of Responsibility
Estrutura © LES/PUC-Rio

10 Padrão Chain of Responsibility
Participantes Handler (Comunicador): Define uma interface para tratar as petições. Implementa o enlace ao sucessor. ConcreteHandler (DebugLogger, Logger) 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

11 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

12 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

13 Padrão Chain of Responsibility
© LES/PUC-Rio

14 Padrão Chain of Responsibility
© LES/PUC-Rio

15 Padrão Chain of Responsibility
© LES/PUC-Rio

16 Padrão Chain of Responsibility
© LES/PUC-Rio

17 Padrão Chain of Responsibility
© LES/PUC-Rio

18 Padrão Chain of Responsibility
© LES/PUC-Rio

19 Padrão Chain of Responsibility
© LES/PUC-Rio

20 Fim!!


Carregar ppt "Elizabeth Suescún Monsalve"

Apresentações semelhantes


Anúncios Google