Como ter classes coesas de ponta a ponta | SOLID com C#: Orientação a Objetos com C# | Alura - Cursos online de tecnologia
Como ter classes coesas de ponta a ponta
Referente ao curso SOLID com C#: Orientação a Objetos com C#, no capítulo Coesão e o Single Responsibility Principle e atividade Vídeo 1
(70.2k xp, 7 posts)
Com relação ao start do código (program.cs) você já definiu qual é o cargo do funcionário e qual a regra que ele irá utilizar, e entendo perfeitamente o motivo desse código "chumbado", já que o foco principal esta em mostrar como de fato aplicar o conceito do SRP.
No entanto estou imaginando isso no mundo real, quando normalmente não temos um cenário tão a favor como está no exemplo da aula. Enfim, minha dúvida é com relação a um passo antes de chegar no program.cs, deixe-me explicar!
Suponhamos que temos um formulário contendo as propriedades dos Funcionário (Cargo também), ao realizar uma requisição ao server, imagino que em algum momento eu teria que fazer uns IFs para poder identificar o cargo selecionado na tela.
E com relação a Regra, eu também teria que fazer uns trechos de código contendo alguns IFs. Não sei se ficou claro, por isso vou tentar ilustrar.
FORMULÁRIO CLIENT SIDE
Dados do Funcionario - Salario Base <input type="text"/> - Cargo <input type="checkbox"/>
public GravarFuncionario(FuncionarioViewModel funcionario) {
if(funcionario.TipoCargo == "Dba")
funcionario.Cargo == new Dba(COMO EU VOU SABER QUAL É A REGRA);
if(funcionario.TipoCargo == "Desenvolvedor")
funcionario.Cargo == new Desenvolvedor(COMO EU VOU SABER QUAL É A REGRA);
Professor espero que tenha ficado claro, minha dúvida esta focada em como eu elimino os IFs, no exemplo acima eu epenas tirei os IFs de um lugar e coloquei em outro. Muito obrigado Professor.
(2671.6k xp, 5740 posts)
Opa, basta que a regra esteja definida dentro da classe do cargo específico. O dba já sabe qual a regra que ele deve aplicar, pq eu preciso passar como argumento no construtor?
Caso essa realmente seja a situação, você, de maneira tradicional, não tem mesmo como fugir do if. Só que tem um detalhe importante, o seu domínio já está utilizando o polimorfismo e está preparado para evoluir... A parte de decidir qual objeto será instanciado está restrita a parte web da app.. Vc pode usar um pouco de reflection para resolver isso.
Entendi. Bem passo pelo construtor porque a classe Dba herda de Cargo. E na classe Cargo força a passagem da regra a ser utilizada. Está bem fiel ao exemplo da aula.
Estou tentando imaginar como poderia fazer essa regra dentro da classe Dba, você tem uma solução simples para ta?
public abstract class Cargo
public IRegraDeCalculo Regra { get; private set; }
public Cargo(IRegraDeCalculo regra) { this.Regra = regra; } }
public class Dba : Cargo {
public Dba(IRegraDeCalculo regra) : base(regra) {
public void SetRegra(IRegraDeCalculo regra) { Regra = regra; } }
public Dba() { SetRegra(new QuinzeOuVintePorCento()); } }
De fato acho que encontrei um caminho legal, que funciona e que não deixou de seguir o princípio SRP. Porém, perdi a função do construtor que é força a passagem da regra de calculo. Por favor, me diga se isso é de fato uma boa solução?
opa, vc pode manter o construtor na mãe.. Na filha, vc declara um construtor sem argumentos e de dentro dele chama o super passando a implementação para a mãe.