Solucionado (ver solução)
Solucionado
(ver solução)
6
respostas

Dúvida no Ex. 2 da Aula 2 - Muitos Descontos e o Chain of Responsibility

Acredito que exista um problema na implementação dos métodos "desconta". A lógica implementada executa o primeiro tipo de desconto encontrado e encerra o fluxo, ou seja, se houver mais de um tipo de desconto, os demais serão ignorados. O correto seria aplicar os descontos de forma cumulativa (caso seja essa a intenção).

Segue a correção a cada um dos métodos:

    //DescontoPorMaisDeCincoItens
    public double desconta(Orcamento orcamento) {
        if (orcamento.getItens().size() > 5)
            return orcamento.getValor() * 0.1 + proximo.desconta(orcamento);
        else
            return proximo.desconta(orcamento);
    }

    //DescontoPorMaisDeQuinhentosReais
    public double desconta(Orcamento orcamento) {
        if (orcamento.getValor() > 500)
            return orcamento.getValor() * 0.07 + proximo.desconta(orcamento);
        else
            return proximo.desconta(orcamento);
    }

    //DescontoPorVendaCasada
    public double desconta(Orcamento orcamento) {
        if (aconteceuVendaCasadaEm(orcamento))
            return orcamento.getValor() * 0.05 + proximo.desconta(orcamento);
        else
            return proximo.desconta(orcamento);
    }
6 respostas

Diego, Bom dia !

bem observado , pode ser feito assim , pois pode ter mais de um caso para o desconto . como pode ter os 3 casos de desconto ( mais de 5 itens, maior que 500 e venda casada )

Único problema é que vai acabar dando mais desconto em seu orçamento , pois irá pegar a regra dos três filtros , acho que o comerciante não irá ficar muito feliz com essa situação e acho que até por isso sempre irá ser feito um dos três pois os desconto é muito grande !

mas bem observado .

obrigado pela sugestão

Bons estudos

Exatamente, isso pode variar muito, cada caso é um caso, mas eu adoraria ter esses descontos rs

solução!

Oi Diego,

Depende! No padrão original do Chain of Responsibility, apenas UM elemento da cadeia responde ao pedido. Ou seja, no nosso exemplo, apenas um desconto será aplicado mesmo!

Se vc quer aplicar vários descontos, vc pode, claro, mas mudou um pouco o padrão original! O que não é problema! :)

Um abraço!

Entendi, é que esse conceito "não cumulativo / agregador" não havia ficado muito claro no conteúdo da aula. Mas claro, tudo depende da regra de negócio desejada (e o padrão mais apropriado).

Aproveitando esse post, gostaria de tirar uma dúvida, se a intenção é sim aplicar uma regra de agregação de valores, qual seria o padrão mais adequado? Por exemplo, e se quiséssemos agregar descontos por planos (dinâmicos), supondo que houvesse uma infinidade enorme de combinações, o ideal seria criar classes específicas para cada plano? Como ficaria a classe responsável pelo mapeamento da cadeia, considerando esse cenário um pouco mais dinâmico?

Você acha que ficaria muito ruim transitar um objeto indicando os tipos de desconto já aplicados?

Abs,

Oi Diego,

Acho que a grande mágica é você perceber que não pode colocar todo o código em uma classe só. Vai ter que separar em várias, pra facilitar legibilidade, manutenção, e etc.

Aí, como vc vai unir todas elas juntas, como quiser! Não há má solução! :)

Um abraço!

Ok, obrigado pelo esclarecimento pessoal. Ainda não tinha trabalhado com esse pattern.