SOLID

Introdução

Recentemente estava buscando ampliar um pouco o meu conhecimento no desenvolvimento back-end, e me deparei com um projeto super legal chamado Web Developer Roadmap 2021, criado por Kamran Ahmed. Basicamente, este estipula alguns “caminhos” a se seguir para você iniciar/melhorar o seu conhecimento acerca do desenvolvimento front-end, back-end e devOps. Vale a pena dar uma conferida se você, assim como eu, tem uma certa dificuldade, dada a grande variedade de tecnologias existentes, de saber onde focar seus estudos.

Na introdução deste roadmap, existe uma lista de noções/tecnologias/metodologias a serem entendidas independente do caminho que você for seguir. Alguns deles eu já domino, como Git, uso básico do terminal, estruturas de dados e licenças. Porém, ainda não me sinto confortável com os demais “requisitos” listados nesta introdução, por isso, irei documentar aqui no Dev.to um pouco dos meus estudos acerca deles.

Vale ressaltar que talvez essa publicação não seja o suficiente para você se aprofundar no tema-chave (indicado pelo título). Porém, ainda assim vale a leitura, já que talvez a minha visão possa agregar um pouco nos seus conhecimentos em relação ao assunto. Então sem mais delongas, vamos iniciar o nosso assunto sobre SOLID!

O que é?

Basicamente, SOLID é um acrônimo criado por Michael Feathers para cinco princípios de design na programação orientada a objetos, com o intuito de criar projetos de software mais compreensíveis, flexíveis e manuteníveis. São eles:

1. Single Responsibility Principle - SRP (Princípio da responsabilidade única)
2. Open Closed Principle - OCP (Princípio do aberto/fechado)
3. Liskov Substitution Principle - LSP (Princípio da substituição de Liskov)
4. Interface Segregation Principle - ISP (Princípio da segregação de interfaces)
5. Dependency Inversion Principle - DIP (Princípio da inversão de dependência)

O primeiro princípio: SRP

“uma classe deve ter apenas uma única responsabilidade.”

A descrição mais clara e formal deste princípio diz que a classe deve ter uma, e apenas uma, razão para mudar. Em outras palavras, poderíamos dizer que uma classe deve ser especializada em um único objetivo dentro do software, ou seja, ela deve executar/desempenhar uma única tarefa/ação.

O segundo princípio: OCP

"entidades de software devem ser abertas para extensão, mas fechadas para modificação."

Em resumo, para termos classes ainda mais coesas e de fácil evolução, elas devem ser modeladas de modo que quando houver mudanças nas regras de negócios, que não haja a necessidade de alteração no código original, mas sim que o comportamento deste possa ser estendido com facilidade.

O terceiro princípio: LSP

“objetos em um programa devem ser substituíveis por instâncias de seus subtipos, sem alterar a funcionalidade do programa.”

O princípio de substituição de Liskov leva esse nome por ter sido criado por Barbara Liskov que introduziu este conceito em uma conferência em 1987 e, posteriormente, em 1994 no artigo Family Values: A behavioral Notion of Subtyping juntamente com Jeannette Wing. A definição original desse princípio, de forma resumida, é a seguinte:

Se q(x) é uma propriedade demonstrável dos objetos x de tipo T. Então q(y) deve ser verdadeiro para objetos y de tipo S onde S é um subtipo de T.

Em outras palavras, toda e qualquer classe derivada deve poder ser usada como se fosse a classe base. Este princípio tem algo bem parecido com a metodologia do projeto por contrato:

• Precondições não podem ser reforçadas em uma sub-classe. Isto significa que não é permitida uma sub-classe com precondições mais fortes que a sua super-classe;
• Pós-condições não podem ser enfraquecidas em uma sub-classe. Isto significa que não é permitida uma sub-classe que contém condições posteriores mais fracas que a super-classe.

O quarto princípio: ISP

“muitas interfaces de clientes específicas, são melhores do que uma para todos propósitos.”

Esse é um princípio um pouco mais simples que os anteriores. Em resumo, basicamente ele diz que é melhor criar interfaces mais específicas ao invés de uma única interface genérica. Uma classe não deve ser forçada a implementar interfaces e métodos que não irão utilizar.

O quinto princípio: DIP

“deve-se depender de abstrações, não de objetos concretos.”

De acordo com Robert Martin (Uncle Bob), este princípio pode ser definido da seguinte forma:

1. Módulos de alto nível não devem depender de módulos de baixo nível. Ambos devem depender da abstração;
2. Abstrações não devem depender de detalhes. Detalhes devem depender de abstrações.

Abstrações tendem a ser estáveis, já as implementações, instáveis. Caso uma classe qualquer precise depender de outro módulo, seria interessante que esta seja uma abstração. Tente ao máximo não depender de outras implementações.

PS: Não confunda Inversão de dependência com Injeção de dependência. São duas coisas diferentes.

Conclusão

Como dito anteriormente, esse é um resumo bem superficial e talvez não seja o suficiente para você se aprofundar no assunto. Contudo, deixo aqui a recomendação de um livro muito bom que abriu muito a minha mente sobre SOLID:

Orientação a Objetos e SOLID para Ninjas - Projetando classes flexíveis, de Mauricio Aniche. Você pode adquirir esse livro clicando aqui.

Obrigado pela leitura e até a próxima! ;)