Design Pattern: Chain of Responsability
Após uma pequena pausa para recuperarmos as energias para a próxima família de Padrões de Projeto, voltamos com a terceira e última fase apresentando a família Comportamental.
Nesta semana estaremos vendo um conceito de encadeamento de responsabilidades, na qual criamos uma série de classes interligadas até que um destes encontra-se responsável por determinado processo, portanto seja bem vindo ao mundo do Chain of Responsability.
Definição GOF
Evita o acoplamento do remetente de uma solicitação ao seu destinatário, dando a mais de um objeto a chance de tratar a solicitação. Encadeia os objetos receptores e passa a solicitação ao longo da cadeia até que um objeto a trate.
Cotidiano
Antigamente falávamos mais em Topologias de Rede, ainda vemos isso porém em menor escala, mediante a modernização das comunicações, aumento do home-office e uso de tecnologias em Cloud, com isso o tratamento para cenários de rede ficou mais específico.
Antes desta revolução tínhamos algo muito mais debatido pois toda e qualquer empresa tinha que passar todo um cabeamento de rede em seu estabelecimento para que seus computadores se comunicassem e atualmente poderia ser dispensado, mediante que fariam uso da rede da própria internet para a maioria das comunicações, de certa forma continuamos utilizando redes.
Este introdutório foi apenas para que recorde-se da época em que discutíamos bastante sobre que topologia seria utilizada em determinada rede, principalmente nos Golden Years de cabos coaxiais e juntamente existia a topologia chamada de Barramento — consiste que um pacote de origem de um computador iria passando por todos os computadores em seu caminho até encontrar o destino correto — assemelha bastante com o padrão que estamos aprendendo hoje, certo?!
Abaixo, temos um desenho da topologia Barramento e observe que os computadores são interligados diretamente entre eles através dos cabos, inexistindo um hub ou roteador.
Diagrama UML
No Diagrama UML, observamos que este padrão não é lá dos mais complexos de entendimento, o que devemos fixar em nossas mentes para esse padrão seria o conceito de Recursividade, pois sem ele este padrão não acontece e veremos mais disso ainda neste artigo. Abaixo temos a definição de cada item do diagrama:
- ConcreteHandler 1, 2, N… — Responsável por lidar com sua responsabilidade, sem conhecer o Handler anterior ou próximo, sua responsabilidade é muito bem definida e limitada, caso este não consiga lidar com determinada responsabilidade será invocado para o Sucessor — daí a recursividade.
- Handler — Interface de ligação sobre todos os ConcreteHandler´s.
- Client — Objeto requisitor para iniciarmos a operação.
Implementação
Em nossa demonstração prática, iremos utilizar um tema que acredito ser conhecido por todos os leitores: Imposto de Renda de Pessoa Física, também conhecido como IRPF, onde o Leão da Receita Federal ataca diretamente no seu bolso.
Pois bem, neste exemplo utilizaremos as faixas de desconto para o salário bruto recebido mensalmente e após informar o salário, será calculado o percentual de desconto, sem muito aprofundamento e de maneira didática, pois o intuito é a demonstração do Chain of Responsability.
No Diagrama de Classe abaixo, podemos observar o que foi dito antes sobre a questão da Recursividade — atente-se a interface IHandler.
A Interface acima representa o Handler, um objeto simples conforme pode observar servindo principalmente para ligação entre os ConcreteHandlers e com isso nossa recursividade funcione.
Nas duas classes acima, temos a representação do ConcreteHandler, porém conforme pode ser visto no código fonte através do GitHub (link para download ao final do artigo) temos outros ConcreteHandlers e pense no cenário que tenhamos alguma Reforma Governamental, não precisamos alterar nada além do que as Classes que concentram as regras de negócio, inclusive caso queira incluir ou excluir faixas e tudo isso será realizado de forma dinâmica — fantástico, não?!
Acima podemos observar a Classe Program representando o Client, neste contexto temos a definição de quem será o próximo para cada cenário através da propriedade Next e requisitamos apenas a instância do faixaIsento com seu método Execute e toda a recursividade fará o trabalho de encontrar a faixa correta.
Pois bem, chegamos ao fim da implementação do primeiro padrão da família Comportamental, espero que tenha ficado claro o conceito e quando devemos implementar, mas para facilitar deixo logo abaixo os prós e contras.
Prós e Contras
Como ponto positivo quero destacar o desacoplamento do remetente ao destinatário e cada vez mais temos certeza que o desacoplamento é importante tanto no Design de código quanto na Arquitetura da solução, por ser algo desacoplado cada nó da cadeia precisa se concentrar apenas em sua regra de negócio sem saber como o próximo tratará e reforço que os nós podem ser adicionados ou removidos dinamicamente, como podemos notar em nosso exemplo a atribuição ao próximo manipulador é feito em tempo de execução.
Jogando contra este padrão, cito a possibilidade da requisição não ser tratada por nenhum dos nós da cadeia, ou seja, chegando ao fim de todo encadeamento sem que seja atendida a requisição e finalizando: seu design fica pouco mais complexo devido o número de manipuladores (handler´s) no projeto.
Código Fonte
Baixe o código fonte em meu GitHub clicando neste link, implemente seus ajustes no Chain of Responsability, evolua com a proposta apresentada neste artigo e comente abaixo sobre suas mudanças.
Finalizando o tema de hoje
Agradecendo a você que está acompanhando mais um artigo sobre Padrões de Projeto e com uma nova família de padrões: Comportamental. Aproveito para dizer que na semana que vem (28/11) estaremos vendo o Padrão State. Não Perca!!!
Forte abraço e até a próxima…
