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

Alternativa para Coesão da Classe Funcionário

Muito Interessante a aula sobre Coesão na Classe Funcionário.

Me surgiu uma duvida.

O Salario poderia ser uma classe?

  1. O reajuste é feito sobre o salario, logo moveríamos o método para dentro dele, assim tendo o encapsulamento do método.
  2. O campo dataUltimoReajuste não é sobre o funcionário e sim sobre o salario. Considerando que podemos reajustar cargo, e locais (não propostos).
  3. E com a criação da Classe Salario poderíamos evoluí-la um histórico de Salario do funcionário e a data de seus ajustes. (não propostos, mas considerando uma "evolução do negocio").

Como ficaria a classe Salario:

Insira aqui a descrição dessa imagem para ajudar na acessibilidade

Como ficaria a classe funcionário:

Insira aqui a descrição dessa imagem para ajudar na acessibilidade

Acredito que não existe uma solução correta, mas propostas e alternativas para chegar em um bom uso da Orientação a Objeto.

E queria entender, essa seria uma boa solução?

2 respostas

Olhando alguns outros tópicos no Forum sobre a mesma aula, acredito que a criação da classe Salario, resolveria o problema de encapsulamento criado pelo atualizarSalario.

REF: https://cursos.alura.com.br/forum/topico-metodo-atualizarsalaraio-160717 , https://cursos.alura.com.br/forum/topico-como-resolver-o-setsalario-disfarcado-145235

solução!

Oi Willian,

Como você disse, não existe uma única solução correta, pois tudo é uma questão de avaliar as vantagens/desvantagens de cada solução.

Eu gostei bastante da sua ideia de ter a classe Salario, visto que de fato salário é algo muito importante nesse sistema e tem regras próprias. Facilita e fica mais fácil de testar, dar manutenção, além de melhorar o encapsulamento e coesão :)

Bons estudos!