Muito se fala dos princípios SOLID no mundo do desenvolvimento de software, principalmente para desenvolvedores backend. Mas afinal, para que serve e quais os principios que o SOLID traz para o nosso dia a dia. É sobre isto que irei falar neste artigo e vou tentar abordar de uma maneira simples e objetiva os princípios
Muito se fala dos princípios SOLID no mundo do desenvolvimento de software, principalmente para desenvolvedores backend.
Mas afinal, para que serve e quais os principios que o SOLID traz para o nosso dia a dia.
É sobre isto que irei falar neste artigo e vou tentar abordar de uma maneira simples e objetiva os princípios SOLID.
De onde surgiu os princípios SOLID?
Os princípios SOLID foram apresentados pela primeira vez por ninguém menos que Robert J. Martin, mais conhecido como Uncle Bob em seu trabalho lançado no ano 2000.
Uncle Bob é autor de diversos livros e a maioria deles muito conhecidos como Código Limpo e Arquitetura Limpa, mas a abreviação SOLID foi apresentada mais tarde por Michael Feathers.
A proposta inicial do SOLID, como podemos observar a seguir é:
“Criar código compreensível, legível e testável, no qual diversos desenvolvedores possam trabalhar de modo colaborativo”.
Estas práticas partem das seguintes premissas, que iremos ter em cada uma das letras do termo SOLID:
- Single Responsability Principle ou Princípio da Responsabilidade Única;
- Open-Closed Principle ou Princípio Aberto/Fechado;
- Liskov Substitution Principle ou Princípio da Substituição de Liskov;
- Interface Segregation Principle ou Princípio da Segregação da Interface;
- Dependency Inversion Principle ou Princípio da Inversão de Dependência.
Nos tópicos a seguir, irei detalhar cada um destes princípios com alguns exemplos.
Princípio de Responsabilidade Única
Como o próprio termo já fala por si só, define que uma classe só deve fazer apenas uma coisa ou ter apenas uma responsabilidade, tendo portanto, apenas uma razão para ser modificada.
Imagine que você tenha uma classe que faça a persistência com a tabela alunos no banco de dados e esta tabela tenha relação com outras entidades, como nota, matéria, etc.
A princípio, entendemos que a classe de persistência dos dados do aluno deve entender apenas da persistência dos dados do aluno.
Então não cabe a esta classe ter outras responsabilidades a não ser persistir os dados do aluno.
Princípio aberto/fechado
Este princípio diz que as classes devem estar abertas para extensão, mas fechadas para modificação.
No caso, modificação entende-se alterar o código de uma classe existente e extensão, significa adicionar novas funcionalidades.
Em outras palavras o que o princípio prega é que devemos modificar uma classe adicionando novas funcionalidades sem tocar no código existente da classe.
Já deve imaginar que isto se deve ao fato que quando colocamos as “patas” no código existente, estamos sujeitos a criar mais bugs em potencial de um código já validado.
Sendo assim, devemos evitar em tocar em código em produção já testado e confiável, se possível.
Mas ai você se pergunta, como é possível mexer em uma classe, adicionar novar funcionalidades sem mexer com esta classe?
E a resposta é simples. Você consegue atingir este objetivo com o auxílio de interfaces e classes abstratas.
Princípio da substituição de Liskov
O nome assusta um pouco, mas o princípio da substituição de Liskov declara que as subclasses devem ser substituíveis por suas classes base.
Trocando em exemplos, isto significa que se uma classe B for uma subclasse da Classe A, devemos passar um objeto da classe B para qualquer método que espere um objeto da classe A e o mesmo não deverá produzir resultados adversos.
Este seria o comportamento esperado, principalmente quando usamos a herança, espera-se que a classe filha herde tudo o que a subclasse tem.
Tenha em mente que a classe herdada estende o comportamento da classe base e nunca o reduz.
Portanto, se a classe não obedece esse princípio, isto pode causar alguns bugs bem dificeis de detectar, a princípio.
Princípio da segregação da interface
Este princípio basicamente tem a ver com separar as interfaces, ou seja, manter as coisas separadas.
Ele nos diz que muitas interfaces específicas do cliente são melhores que uma interface de propósito geral, não sendo os clientes forçados a implementar uma função que não necessitam.
Neste ponto aqui, eu imagino que você já deve ter em mente aquele projeto da sua firma que tem aquela interface cabulosa que implementa tudo.
Ela com certeza fere diretamente este princípio. Agora, fica uma questão, mexer nela?
Princípio da inversão da dependência
Já o último princípio SOLID nos diz que nossas classes devem depender de interfaces ou de classes abstratas em vez de classes concretas e de funções.
O próprio Uncle Bob e um artigo publicado em 2000, resume este princípio da seguinte maneira:
“Se o princípio de aberto/fechado declara o objetivo da arquitetura orientada a objetos, o princípio de inversão da dependência declara seu mecanismo principal”
Não preciso afirmar que você deve ter na veia estes princípios para trabalhar como um desenvolvedor e acredite, é saudável para todos do time.
Eu não me recordo mais do dia que não trabalhei com este e outros princípios no meu dia a dia ou no da equipe que trabalho.
Realmente é perturbador quando pegamos um projeto legado em que grande parte do código está fortemente acoplado e não conseguimos praticamente mexer em nada sem estragar o restante.
Então, sempre tenha em mente estes princípios do SOLID e repita este mantra todos os dias em seu código e nas suas aplicações.
Leave a Comment
Your email address will not be published. Required fields are marked with *