1
resposta

Uma outra possibilidade para resolver a questão do encapsulamento

Pensei que talvez ainda pudesse ser mantido o método reajusteSalarial dentro da classe Funcionario, mas agora, ao invés de realizar a lógica, ele invocaria o serviço de reajuste. Com o retorno do serviço faria a atualizaçao do salário em um método atualizaSalario privado.

Para evitar o acomplamento entre Funcionario e a classe de serviço, a instancia do serviço poderia ser passada por parametro. Ainda poderia ser feito através de uma interface, onde ainda seria possível ter várias implementaçoes da regra de reajuste de funcionário.

Só coloquei essa ideia porque a outra solução de colocar o serviço e a entidade no mesmo pacote, ao menos pra mim, não ficou tão legal.

Gostaria de saber se essa possibilidade também funcionária bem dentro das bases do SOLID?

1 resposta

Oi Ruy,

Acho que funcionaria desse jeito também.

A grande questão é que dificilmente teremos uma solução que somente terá vantagens. Sempre uma solução terá também suas desvantagens e as vezes uma solução favorece algum princípio SOLID e/ou da orientação a objetos, mas pode estar "ferindo" outros.

Então ideal é sempre avaliar as vantagens e desvantagens de cada solução e ponderar quando vale a pena utilizar cada uma.

Bons estudos!

Quer mergulhar em tecnologia e aprendizagem?

Receba a newsletter que o nosso CEO escreve pessoalmente, com insights do mercado de trabalho, ciência e desenvolvimento de software