Skip to content

Projeto desenvolvido com o objetivo de aplicar e compreender melhor os princípios SOLID

Notifications You must be signed in to change notification settings

GSilvaO/java-solid

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

3 Commits
 
 
 
 
 
 
 
 

Repository files navigation

Conceitos SOLID

Abaixo será descrito como os conceitos de SOLID foram aplicados na confecção desta aplicação

S (Single Responsibility Principle)

A classe Funcionario possuia um método chamado reajustarSalario(). Apesar deste método estar relacionado a um funcionário não é interessante deixa-lo na classe de domínio pois é um método que pode vir a mudar e podem ser acrescentadas novas regras com certa frequência neste método, fazendo com que a classe Funcionário distoe de sua função principal, que seria a de representar um funcionário no sistema. Este método foi refatorado para uma nova classe de serviço chamada ReajusteService para que a responsabilidade de reajuste salarial fique limitada a esta classe.

O (Open-Closed Principle)

Ao realizar a refatoração do método reajustarSalario() para a classe ReajusteService foi criado o método reajustarSalarioDoFuncionario() nesta classe. Foi observado que neste método validações deveriam ser feitas, e, caso uma nova validação fosse necessária, a tendência era esta classe crescer indefinidamente. Para resolver este problema, foi criada uma interface chamada ValidacaoReajuste com um método chamado validar(), e também foram criadas duas classes de validação que implementam esta interface, a classe ValidacaoPercentualReajuste e a classe ValidacaoPeriodicidadeEntreReajustes. Desta forma, foi possível passar para a classe ReajusteService a interface ValidacaoReajuste, fazendo com que caso seja necessário adicionar uma nova validação, basta a classe desta validação extender a interface ValidacaoReajuste e implementar seu método. Assim, a classe ReajusteService fica aberta para mudanças e fechada para modificações.

L (Liskov-Substitution Principle)

Em um cenário onde uma empresa pode contratar terceirizados, foi criada a classe Terceirizado para representar um terceirizado. Porém, uma indagação válida é se esta classe deveria herdar da classe Funcionario, já que esta classe possui um método chamado promover() e outro chamado atualizarSalario(), onde não faria sentido a classe Terceirizado possuir estes métodos já que a empresa contratante não seria a responsável por gerenciar assuntos relacionados ao salário e ao cargo de um funcionário terceirizado. Além disso, na classe de serviço ReajusteService, o método de reajuste teria que ser modificado para lidar com o caso de um terceirizado ser passado de maneira polimórfica, violando, desta forma, o princípio de substituição de Liskov. A alternativa para lidar com esta situação foi, já que a classe Terceirizado necessitava apenas de alguns atributos em comum com a classe Funcionario, estes atributos foram extraídos para uma nova classe chamada DadosPessoais, onde foi realizada a composição desta classe nas classes de Funcionario e Terceirizado.

I (Interface Segregation Principle)

A interface Reajuste foi criada com o objetivo de conter métodos relevantes para a operação de um reajuste. A classe Anuenio implementa esta interface, na qual o objetivo é fazer a lógica de reajuste salarial anual. Porém, quando um funcionário é promovido, além do reajuste salarial também há uma tributação adicional em cima deste valor e esta tributação foi, como exemplo, o valor do imposto de renda. Caso a interface Reajuste possuísse este método de valorDoImpostoDeRenda(), a classe Anuenio seria obrigada a implementa-lo e, desta forma, estaria violando o princípio de segregação de interfaces, que diz que uma classe não deveria ser forçada a implementa um método que não irá utilizar. A solução para isto foi criar uma nova interface chamada ReajusteTributavel que herda da interface Reajuste. Foi também criada uma classe chamada Promocao onde esta, por sua vez, implementa o ajuste tributável.

D (Dependency Inversion Principle)

No método reajustarSalarioDoFuncionario() da classe ReajusteService acontecem validações para garantir que o reajuste salarial de um funcionário siga certas regras de negócio. Essas validações são implementações da interface ValidacaoReajuste, conforme explicado acima. Um fato interessante é que a criação das instâncias destas classes não são chamadas na classe ReajusteService mas injetadas no construtor através da passagem de uma lista das instância das validações. Com isso, nós invertemos a responsabilidade da criação das instâncias destas classes. O método reajustarSalarioDoFuncionario() possui um loop que irá percorrer essas instâncias e chamar o método validar() de cada validação.

About

Projeto desenvolvido com o objetivo de aplicar e compreender melhor os princípios SOLID

Topics

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published