Executando verificação de segurança...
2

Design Patterns - Chain Of Responsability

Chain of Responsability

Pessoal, este é um artigo (resumo do resumo rs) produzido por mim em meus estudos no ciclo de PDI na minha atual empresa. Imaginei que pudesse, mesmo que de forma limitada, ajudar outras pessoas a entender um pouco melhor sobre esse padrão de projeto e resolvi compartilhar.

Ao final do artigo há dois exemplos do padrão CoR feitos com Java. Um utilizando apenas Java e outro utilizando também Spring. :)

Chain of Responsibility é um padrão de projeto que cria uma cadeia de execução na qual cada elemento processa as informações e em seguida delega a execução ao próximo da sequência. Em sua implementação tradicional, os elementos são percorridos até que um deles faça o tratamento da requisição, encerrando a execução depois disso. Como alternativa, também é possível criar uma cadeia de execução onde cada um executa sua funcionalidade até que a cadeia termine ou ela seja explicitamente finalizada por um dos elementos.
— Eduardo Guerra, Design Patterns com Java


chain of responsability


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. — GOF, Design Patterns


Qual problema visa resolver?

  • Cenário onde há a necessidade de realizar diversas verificações para execução de um processo.
    • Ex.: Autorização de um usuário no sistema para executar somente as funcionalidades permitidas.
    • [login (usuário e senha)] → [validar token] → [validar permissão]
    • Se surgir a necessidade de incluir mais verificações?
    • Se surgir a necessidade de reaproveitar esse comportamento em outros módulos do sistema?

O padrão também aborda maneiras diferentes de regras de funcionamento. Há casos que fazem sentido apenas um handler (componente) tratar a requisição e mais nenhum.

chain of responsability example

Prós e Contras:

  • Prós:
    • Você pode controlar a ordem de tratamento dos pedidos.
    • Princípio de responsabilidade única. Você pode desacoplar classes que invocam operações de classes que realizam operações.
    • Princípio aberto/fechado. Você pode introduzir novos handlers na aplicação sem quebrar o código cliente existente.
  • Contras:
    • Alguns pedidos podem acabar sem tratamento.

Materiais de apoio e fontes:

Exemplos de código feitos:

Caso de Uso: Validação em etapas para dados cadastrais de uma pessoa. Foi criada uma chain para aplicar diversas validações.

Carregando publicação patrocinada...
1

Obrigado pela postagem. Admito que sempre tive dificuldades em entender as aplicações de design patterns em situações reais.
Na faculdade estudei diversos modelos, mas por vezes entendia apenas como um exercício de praticar a codificação, ou até bases de conteúdo programático para passar em provas.

Sucesso por aí e obrigado pelos materiais.