Violações de princípios

Oi Paulo, ótimos pontos. Como o exercício falou, também acho que não tem resposta correta... A classe ter uma responsabilidade é um ótimo principio, mas isso não impede a mesma classe de ser composta por outra para atingir uma regra. É a sacada do dividir para conquistar, podem existir classes no seu sistema, muitas vezes de regra de negócio mesmo, que juntem várias outras.

Como disse, nesse momento essa classe poderia até ser apagada, mas também não vejo nenhum mal em deixar ela.

Alberto, obrigado pela sua atenção e resposta.

Sobre ela ser composta por outras classes que ajudem a atingir uma regra, discordo. Ela será uma classe pouco coesa, pois essa função não é regra dela. Ao ler o projeto a classe calculadora seria o último lugar que eu olharia para achar um método Que altera status de um orçamento. Afinal ela é uma calculadora e espero dela apenas cálculos!! Mas aceitando que isso seja uma questão de interpretação, os outros dois princípios ainda me fazem achar que essa classe não deveria existir. Por exemplo o OCP que me diz que eu não posso mais alterá-la pois ela deveria estar fechada, mas eu posso estendê-la, ou seja, se precisarei criar uma outra classe que estende la, pq não criar uma mais coesa?

Abraços.

O principio do aberto para extensão e fechado para modificação é super importante e está mantido. Você pode criar outras implementações do Imposto que a Calculadora não sofreria modificações.

Em algum lugar do seu sistema vc precisa de classes que amarrem outras... Não existe um sistema 100% desacoplado, pq aí ele não seria sistema... O que vc luta é para diminuir o acoplamento e aumentar a coesão.. Não precisa de exagero :).

Não sei se ainda estamos falando do mesmo assunto. Mas sim "lutamos" para aumentar a coesão, e foi por isso que abri esse tópico, porque o argumento usado pela correção não foi o melhor e pode induzir o novo estudante a um hábito de pensar "sem exagero" que reduzirá a coesão.

Eu não falei NADA sobre sistema 100% desacoplado, falei sobre COESÃO!!!! Entendo claramente a diferença entre esses dois e não seria idiota de falar isso nessa pauta.

Enfim. Vamos manter então uma calculadora que altera status do orçamento e do meu lado estarei torcendo para não encontrar pela frente códigos escritos por alunos daqui que aprenderem a "não exagerar"!!! Kkkkk

Abraços!

Oi Paulo, se vc busca aumentar a coesao, vai diminuir o acoplamento, justamente pq vc vai ter classes mais focadas. As duas coisas andam juntas, pelo menos pra mim.

Em relação a classe Calculadora,desde o início disse que concordava que ela podia sumir, mas também achei aceitável ela ser mantida.

A parte do exagero, eu também acho super importante. Design de código eh muito importante, mas o programador, na minha opinião, tem que ter sempre em mente que o tipo de projeto que ele tá desenvolvendo vai guiar as soluções de design. Tô fazendo um Framework? Vou me preocupar com vários pontos de extensão. Tô fazendo um relatório que ja me disseram que vai mudar? Criarei pontos de extensão. Tô fazendo algo que ja tem dia pra morrer e não pensam em nada a mais? Vou fazer mais simples.

Acho que eh isso, perceba que não fui irônico em nenhum dos meus comentarios. So não concordo 100% com seu ponto de vista e quis fomentar a discussão.

Alberto, Compreendo e respeito seu ponto de vista, e agradeço pela sua atenção.

Tenha um bom dia.

Chegando aqui para dar meus 2 centavos para a discussão, a classe como foi apresentada realmente tem pouca ou quase nenhuma utilidade, nos meus testes aqui transformei ela para ficar assim:

    public class CalculadorDeImposto
    {
        public double Calcula(Orcamento orcamento, Imposto estrategiaDeImposto)
        {
            double resultado = estrategiaDeImposto.Calcula(orcamento);
            return resultado;
        }
    }

Agora ela segue o que indica ( calcular imposto ) e tem uma utilidade que é retornar o valor do imposto já calculado.

Resumindo, pode continuar existindo, mas precisa de ajustes.