Se você é desenvolvedor e está começando a estudar como escrever seu código de uma forma mais sustentável, onde cada responsabilidade está bem dividida, e com isso, seu código não fica extremamente complexo de fazer manutenção, você já se deparou com o SOLID. Hoje, nós vamos destrinchar um pouco do que significa o SOLID e como você consegue aplicar ele no seu código!
O que é o SOLID?
As primeiras ideias sobre o Solid começaram a aparecer com o cientista da computação Robert J.Martin (o famoso Uncle Bob).
Mas vamos do começo, o que é o SOLID? O SOLID nada mais é que os cinco princípios da programação orientada a objetos, uma vez que a mesma, busca facilitar o desenvolvimento de software.
Ele se divide em:
- S – Single Responsibility Principle (Princípio da responsabilidade única)
- O – Open-Closed Principle (Princípio Aberto-Fechado)
- L – Liskov Substitution Principle (Princípio da substituição de Liskov)
- I — Interface Segregation Principle (Princípio da Segregação da Interface)
- D — Dependency Inversion Principle (Princípio da inversão da dependência)
Com esses princípios, seu código se torna cada vez mais desacoplável, e assim, mais fácil de refatorar e aproveitar código já existente.
Agora vamos entender melhor o que significa cada letra? Vem comigo!
S – Single Responsibility Principle
Esse principio declara que uma classe deve fazer uma única coisa, e com isso, ter um, e somente um motivo para mudar. Quando uma classe tem muitas responsabilidades, a possibilidade de bugs aumenta porque uma vez alterada uma das responsabilidades, outras podem ser afetas sem a sua percepção. Por isso, a mesma deve ser especializada em apenas um “assunto”.
Fonte: Ugonna Thelma
O – Open-Closed Principle
Em seguida temos o O, que visa entender o comportamento de uma classe sem alterar o comportamento existente dessa classe, e com isso, a mesma evita causar bugs onde quer que a classe esteja sendo usada.
Em outras palavras, quando novos comportamentos precisam ser adicionados em uma classe ou no software, é preciso estender a classe e não alterar o código fonte.
Geralmente esse processo é feito com o auxílio de classes abstratas e interfaces. Um caso simples, por exemplo, é você precisar salvar um resultado de uma pesquisa.
Partindo desse principio, cria-se uma interface para dizer quais os métodos essa pesquisa terá, e uma classe para implementar de fato essa funcionalidade:
Fonte: Ugonna Thelma
L – Liskov Substitution Principle
Esse princípio declara que as subclasses devem ser substituíveis por suas classes base. Esse provavelmente é o princípio mais complexo, mas para facilitar, podemos supor o seguinte:
“se S é um subtipo de T, então os objetos do tipo T, em um programa, podem ser substituídos pelos objetos de tipo S sem que seja necessário alterar as propriedades deste programa. — Wikipedia.“
Fonte: Ugonna Thelma
Um exemplo disso é: preciso criar duas classes, onde uma dessas estende da outra, então as duas ficam assim:
I — Interface Segregation Principle
Os clientes não devem ser forçados a depender de métodos que não usam.
Esse principio é baseado inteiramente nesse ideia, ou seja, quando uma classe é obrigada a executar ações que não são úteis, pode resultar em uma série de bugs inesperados, caso a mesma não seja capaz de executar essas ações.
Em resumo, esse princípio diz que é melhor criar interfaces específicas do que uma interface genérica:
Fonte: Ugonna Thelma
D — Dependency Inversion Principle
Nesse princípio temos como base que as abstrações não devem depender de detalhes. Os detalhes devem depender de abstrações…
Segundo Uncle Bob: “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”.
Para que nossas classes sejam abertas para extensões, é necessário organizar as mesmas para que elas dependam de interfaces, e não de classes concretas. Portanto, esse princípio visa reduzir a dependência de uma classe alto nível de uma de baixo, introduzindo uma interface.
Fonte: Ugonna Thelma
Conclusão
Seguindo os princípios do SOLID, seu código pode ficar de certa forma mais “inteligente”, uma vez que cada funcionalidade, e principalmente responsabilidade, vão ficar separadas.
Se caso seja necessário fazer manutenções no código, ou até grandes mudanças, com o SOLID as mesmas tendem a ficar mais fáceis, e com isso, seu código pode se tornar mais “duradouro” e sem bugs.
Veja também…
Se você quiser saber um pouco mais sobre Programação Orientada a Objetos, dá uma olhadinha nesses outros conteúdos que já soltamos por aqui:
Pilares de Orientação a Objetos
