1
resposta

Ideia sobre o método de reajustar salário

public class Funcionario {

    private String nome;
    private String cpf;
    private Cargo cargo;
    private BigDecimal salario;
    private LocalDate dataUltimoReajuste;

    private ReajusteService reajusteService;

    public Funcionario(String nome, String cpf, Cargo cargo, BigDecimal salario) {
        this.nome = nome;
        this.cpf = cpf;
        this.cargo = cargo;
        this.salario = salario;
        this.reajusteService = new ReajusteService(this);
    }

    public void reajustarSalario(BigDecimal aumento) {
        this.salario = reajusteService.reajustarSalarioDoFuncionario(aumento);
        this.dataUltimoReajuste = LocalDate.now();
    }
    ///////
public class ReajusteService {

    private Funcionario funcionario;

    public ReajusteService(Funcionario funcionario){
        this.funcionario = funcionario;
    }

    public BigDecimal reajustarSalarioDoFuncionario(BigDecimal aumento){
        BigDecimal percentualReajuste = aumento.divide(funcionario.getSalario(), RoundingMode.HALF_UP);
        if (percentualReajuste.compareTo(new BigDecimal("0.4")) > 0) {
            throw new ValidacaoException("Reajuste nao pode ser superior a 40% do salario!");
        }
        return funcionario.getSalario().add(aumento);
    }

}

Sobre o problema de encapsulamento do método de reajuste, eu pensei nessa solução fazendo uma composição, gostaria de saber se é uma solução viável

1 resposta

É uma solução viável e com certeza funciona, mas é interessante pensarmos nos conceitos de acoplamento e coesão, que foi discutido na primeira aula.

Foi estabelecido no exercício que a classe Funcionário representa um funcionário da empresa. Se pensarmos nas propriedades de um funcionário, a instância de ReajusteService não é uma propriedade de um Funcionário. Apesar de termos removido a lógica do reajuste salarial da classe funcionário, criamos uma dependência entre a classe Funcionário com a classe ReajusteService. Essa dependência aumenta o acoplamento e diminui a coesão, pois a classe Funcionário ficou mais complicada.

Se por algum motivo no futuro a classe ReajusteService mudar e receber um parâmetro novo no construtor, teríamos que mudar a implementação da classe funcionário e isso não é o ideal.

Legal lembrar do Princípio de Responsabilidade Única: uma classe deve ter "apenas" uma razão para mudar

Espero ter ajudado! Por favor aceite a resposta se estiver boa :) Bons estudos!