Guia rápido para os pricípios SOLID aplicados a Orientação a Objeto.
Quem programa usando POO se depara com 5 principais princípios que vão te ajudar a escrever códigos melhores também conhecidos como SOLID. Neste artigo eu pretendo desmistificar esses princípios.
SOLID
Para começar, já vou dizer que SOLID é acrônimo de:
- Single responsibility principle (Princípio da responsabilidade única).
- Open/closed principle (Princípio aberto/fechado).
- Liskov substitution principle (Princípio da substituição de Liskov).
- Interface segregation principle (Princípio da segregação da interface).
- Dependency inversion principle (Princípio da inversão da dependência).
S — Princípio da responsabilidade única
Pensa em uma calculadora, classe da calculadora precisa ter uma responsabilidade única. Uma classe para operações, uma para guardar e exibir o histórico das operações por exemplo. Na classe de operações teríamos uma função para somar, outra pra dividir, outra pra subtrair e outra pra multiplicar. Se tivermos que converter os resultados obtidos para Json, o mesmo deve pertencer a outra Classe exclusiva.
O — Princípio aberto/fechado
Ser capaz de estender o comportamento de uma classe sem modificá-la. Aberta para extensão e fechada para modificação.
É preciso alterar a classe Saveimg, a classe tem de estar fechada para alteração isso fere o princípio aberto/fechado.
Vamos refatorar o nosso código.
Fica mais fácil implementar outros formatos que essa imagem upada será salva sem alterar a classe principal.
L — Princípio da Substituição de Liskov
A explicação para esse principio é complicada mais em resumo, quando extendemos uma classe as classes herdadas precisam ter o mesmo comportamento.
Lembra da nossa calculadora?
- class Opera recebe valor1 e valor2;
- class Soma extends Opera e tem uma função que soma valor1 e valor2;
- class Multiplica extends Opera e tem uma função que multiplica valor1 e valor2;
Percebe que tanto uma classe como a outra trazem métodos com a mesma estrutura. Basicamente é isso. Lembrando que esse principio se aplica apenas para classes que se extendem de uma mesma classe.
I — Princípio da segregação da interface
Segregar significa separar.
Todas as aves voam? Todas as aves nadam? O conceito diz que uma regra na interface não deve existir se ela não for de fato usada pela classe que a implementa. Em outras palavras, precisamos criar pequenas interfaces mais específicas ao invés de termos uma única genérica.
Segue um exemplo que retirei de: https://imasters.com.br/back-end/solid-com-php
Ficou claro e óbvio né?!
D — Princípio da inversão da dependência
Quando você cria uma classe para resolver um problema ela é uma implementação certo. Não podemos criar uma classe posterior que dependa dessa classe existente, ela precisa depender de uma interface.
Vou pegar um exemplo desse post: https://medium.com/@felippeduarte/os-princ%C3%ADpios-solid-dip-dd72024b4917
Afinal todos aqui no médium somos colegas não é mesmo. Aproveite para seguir o Felippe Roberto Bayestorff Duarte! :D
Observe que a classe MailMarketing cria uma dependência com a Classe Mail, instanciando ela na função enviar. Isso fere as regras da inversão de dependência.
Agora vamos fazer com que essa dependência esteja ligada a uma interface que seria o correto e faremos isso usando um construtor para fazer a instância de uma classe dentro da outra, dá uma sacada nesse código:
Essa foi a melhor aplicação que vi na internet.
Conclusão
Como você deve ter imaginado ao ler esse post nem sempre será possível ou mesmo muito complicado usar todos os princípios em todas as classes do nosso projeto, eles são um guia para te ajudar a escrever códigos maduros.
Se você gostou dessa matéria, leia:
Att,
