Você está na página 1de 6

Relatório Padrões de Projeto: Chain Of Responsibility e

Command
Karen Cristina Violim1 , Santiago Molina1
1
Campus Paranavaı́ - Instituto Federal do Paraná (IFPR)
Paranavaı́ - PR - Brasil.
{karenifpr@gmail.com, santiago.molina493@gmail.com}

1. Padrão de Projeto - Chain Of Responsibility (Cadeia de Responsabilidade)


• Intenção: Evitar o acoplamento do remetente de uma solicitação ao seu receptor,
ao dar a mais de um objeto a oportunidade de tratar a solicitação. Encadear os
objetos receptores, passando a solicitação ao longo da cadeia até que um objeto a
trate.
• Motivação e Utilidade: Quando temos uma determinada regra/processo que tem
uma dependência entre objetos em hierarquia ou sequência, utilizamos o padrão
de modo a encadear o processamento entre vários objetos, onde cada um recebe a
solicitação, trata, e se necessário envia a um novo objeto para continuar o proces-
samento, fornecendo uma maneira de tomar decisões com um fraco acoplamento.
• Explicação Teórica: Vimos que o padrão Chain of Responsibility fornece uma
maneira de tomar decisões com um fraco acoplamento. Perceba que a estrutura de
cadeia não possui qualquer informação sobre as classes que compõem a cadeia, da
mesma forma, uma classe da cadeia não tem nenhuma noção sobre o formato da
estrutura ou sobre elementos nela inseridos. Assim, é possı́vel variar praticamente
todos os componentes sem grandes danos ao projeto. Cada elemento implementa
sua própria maneira de responder a requisição, e estas podem ser alteradas facil-
mente. O problema é que é preciso tomar cuidado para garantir que as chamadas
sejam realmente respondidas.
• Apresentação da Estrutura:

Handler - define uma interface para manipular solicitações.


ConcreteHandler - trata de solicitações pelas quais é responsável. Pode acessar
seu sucessor. Se puder tratar a solicitação, ele assim o faz; caso contrário, ele
repassa a solicitação para o seu sucessor.
Cliente - envia comandos para o primeiro objeto na cadeia que pode manipular o
comando.

• Apresentação de 1 exemplo de implementação em Java:


Vamos então iniciar construindo uma pequena enumeração para identificar os ban-
cos utilizados no nosso sistema:

Agora vamos construir a classe que vai implementar a cadeia de responsabilida-


des. Vamos exibir partes do código para facilitar o entendimento.

A nossa classe possui apenas dois atributos, o identificador do banco e uma re-
ferência para o próximo objeto da corrente. No construtor inicializamos estes atri-
butos. O método setNext recebe uma nova instância da classe e faz o seguinte: Se
o próximo for nulo, então o próximo na corrente será o parâmetro. Caso contrário,
repassa esta responsabilidade para o próximo elemento. Assim, a instância que
deve ser adicionada na corrente irá percorrer os elementos até chegar no último
elemento.
O próximo passo será criar o método para efetuar o pagamento.
A primeira parte do algoritmo de pagamento é verificar se o banco atual pode fa-
zer o pagamento. Para isto é utilizado o identificador do banco, que é comparado
com o identificador passado por parâmetro. Se o elemento atual puder responder a
requisição é chamado o método que vai efetuar o pagamento de fato. Este método
é abstrato, e as subclasses devem implementá-lo, com seu próprio mecanismo.
Se o elemento atual não puder responder, ele repassa a chamada ao próximo ele-
mento da lista. Antes disto é feita uma verificação, por questões de segurança, se
este próximo elemento realmente existe. Caso nenhum elemento possa responder,
é disparada uma exceção.
Agora que definimos a estrutura da cadeia de responsabilidades, vamos imple-
mentar um banco concreto, que responde a uma chamada.

O Banco A inicializa seu ID e, no método de efetuar o pagamento, exibe no ter-


minal que o pagamento foi efetuado. A implementação dos outros bancos segue
este exemplo. O ID é iniciado e o método de efetuar o pagamento exibe a saı́da
no terminal.
E por fim, o cliente deste código seria algo do tipo:
• Apresentação de exemplos reais nos quais o padrão foi ou pode ser aplicado:
Ao projetar um sistema de envio para pedidos eletrônicos.
As etapas para concluir e lidar com o pedido difere de uma ordem para outra com
base no cliente, no tamanho da ordem, na forma de envio, no destino e em outras
razões. A lógica de negócios também é alterada à medida que casos especiais
aparecem, precisando que o sistema seja capaz de lidar com todos os casos.
O Cliente, a ordem eletrônica em andamento, solicita o envio com base em um
conjunto de informações. Sua solicitação é transformada pelo sistema em um
formulário especı́fico, combinando as etapas de preenchimento e os detalhes de
manuseio, com base nas informações de entrada. O sistema enviará esse tipo
de solicitação por meio de uma cadeia de manipuladores de pedidos até que
as informações de entrada correspondentes sejam correspondentes à entrada das
alças de pedidos. Quando casos especiais aparecem, tudo o que é necessário é um
novo manipulador a ser adicionado na cadeia.

2. Padrão de Projeto - Command


• Intenção: Encapsular uma solicitação como objeto, desta forma permitindo pa-
rametrizar cliente com diferentes solicitações, enfileirar ou fazer o registro de
solicitações e suportar operações que podem ser desfeitas.
• Motivação e Utilidade: Algumas vezes é necessário emitir solicitações para obje-
tos que nada sabem sobre a operação que está sendo solicitada ou sobre o receptor
da mesma.
• Explicação Teórica: O padrão Command é um padrão simples e muito utili-
zado. Porém ele possui alguns detalhes importantes que precisam ser notados,
caso contrário sua implementação pode não trazer tanta reutilização.
O Command tem como objetivo encapsular uma s olicitação como um objeto, o
que permite parametrizar outros objetos com diferentes solicitações, enfileirar ou
registrar solicitações e implementar recursos de cancelamento de operações (des-
fazer). Ou seja, o objetivo do padrão é transformar um método de uma classe em
um objeto, o qual pode executar a ação deste método.
Exemplificando, imagine um portão eletrônico que você queira abrir, não é ne-
cessário saber como funciona o mecanismo que faz o portão abrir ou de que o
portão é feito, você apenas quer abrir o portão e por isso aperta um botão que faz
ele abrir.
• Apresentação da Estrutura:

Command – declara uma interface para a execução de uma operação.


ConcreteCommand – define uma vinculação entre um objeto Receiver e
uma ação; implementa Execute através da invocação da(s) correspondente(s)
operação(ões) no Receiver.
Client – cria um objeto ConcreteCommand e estabelece o seu receptor.
Invoker – solicita ao Command a execução da solicitação.
Receiver – sabe como executar as operações associadas a uma solicitação. Qual-
quer classe pode funcionar como um Receiver.
• Apresentação de 1 exemplo de implementação em Java:
Vamos primeiro definir a interface comum aos objetos que processam um paga-
mento. Todos eles possuem um mesmo método, processar pagamento, que toma
como parâmetro uma compra e faz o processamento dessa compra de várias for-
mas.

Uma possı́vel implementação seria a de processar um pagamento via boleto. Va-


mos apenas emitir uma mensagem no terminal para saber que tudo foi executado
como esperado:

Agora o método de execução da compra na classe Loja seria assim:


O código cliente que usaria o padrão Command seria algo do tipo:

Ao executar uma compra nós passamos o comando que deve ser utilizado, neste
caso, a forma de pagamento utilizado.
• Apresentação de exemplos reais nos quais o padrão foi ou pode ser aplicado:
Podemos considerar o exemplo de uma oficina de reparação automática. As pes-
soas entram com carros diferentes que têm problemas diferentes. A pessoa na
recepção pega suas informações e coloca o carro em uma fila para conserto. As
informações no pedido são encapsuladas no papel que o proprietário do carro usará
quando voltar para pegar o carro fixo. Em algum momento, o carro se tornará o
primeiro item na fila e o mecânico irá consertá-lo. Os atores no cenário são os
seguintes: O cliente é o cliente. O Invocador é a pessoa na recepção que leva as
informações sobre o carro e seus problemas, o ConcreteCommand é o pedido para
consertar o carro e o Receptor é o mecânico.

Referências
https://brizeno.wordpress.com/category/padroes-de-projeto/chain-of-responsibility/.
https://brizeno.wordpress.com/category/padroes-de-projeto/command/.
https://imasters.com.br/desenvolvimento/arquitetura-e-desenvolvimento-de-software-
parte-14-chain-responsability.
https://www.oodesign.com/chain-of-responsibility-pattern.html.
https://www.oodesign.com/command-pattern.html.
http://www.csi.uneb.br/padroes de projetos/command 2.html.
GAMMA, E. e. a. (2008). Padrões de Projeto: Soluções reutilizáveis de software orien-
tado a objetos.

Você também pode gostar