Entenda o SOLID de uma vez por todas e por que é tão importante!
Certamente se você já atua com desenvolvimento a algum tempo já deve ter ouvido sobre Robert Cecil Martin, também conhecido como “Uncle Bob”, é uma grande personalidade da comunidade de desenvolvimento de software, autor de vários artigos, vídeos e livros como Clean Code, que por sua vez também descreve bem todos os princípios e aplicabilidade desse acrônimo.
Ok, mas do que se trata o SOLID ?
Basicamente tratam-se de 5 princípios importantes para o desenvolvimento de forma escalável, testável de fácil manutenção e entendimento.
Cada vez mais requisitado no mercado o conhecimento prático desses princípios é de extrema importância para as empresas e todo profissional de software.
Bom, agora que você já sabe para que serve o SOLID vamos aos princípios, sendo o primeiro e mais conhecido
S(Single Responsibility Principle)
Tio Ben estava certo! E o "tio Bob" também. Com grandes poderes temos grandes responsabilidades.
Do que o SRP trata-se ?
“Uma classe deve ter um, e apenas um, motivo para ser modificada”
Ele defende fundamentalmente sobre o momento do design de nossas classes, onde nessa etapa as melhores classes são aquelas que possuem uma e única responsabilidade definida. Mas o que seria responsabilidade ?
Imagine uma classe Employee que possui as seguintes funções:
- calculatePayOff( )
- saveInfo( )
- describeEmployee( )
Logo ela possui 3 responsabilidades sendo elas: salary calculation, information persistence e reporting. Isso trata-se de uma classe que não atenderia ao SRP. Em cima dessa problemática Uncle bob sugere que podemos distinguir essas responsabilidades em classes apartadas, como o método describeEmployee( ) estaria ligado a um sistema de reporting, o calculatePayOff( ) estaria ligado a um sistema de pagamento e o saveInfo( ) estaria ligado a um sistema de persistência.
O(Open Closed Principle)
Sinceramente esse foi o que mais demorei para entender como aplica-lo na prática. Seu conceito teórico é bem simples de entender na verdade, mas não conseguia imaginar como implementa-lo de forma que cumprisse seus princípios, e foi aí que encontrei um pattern perfeito para isso, o Strategy Pattern 🙌🏼
Com ele você pode introduzir novas estratégias sem mudar o contexto.
O Strategy é um padrão de projeto comportamental que permite que você defina uma família de algoritmos, coloque-os em classes separadas, e faça os objetos deles intercambiáveis.
- 📄 Mergulho nos padrões de projeto — Alexander Shvets
O Open-Closed Principle (OCP) é um dos princípios do SOLID que afirma que as classes devem ser abertas para extensão, mas fechadas para modificação. Isso significa que você pode estender as funcionalidades de uma classe sem alterar seu código.
O strategy pattern é design pattern que ajuda a implementar o OCP. O strategy pattern permite que você escolha uma estratégia específica para realizar uma tarefa, sem precisar modificar o código da classe.
Por exemplo, imagine que você está desenvolvendo um software para calcular o imposto devido por uma empresa. Dependendo do país em que a empresa está localizada, o cálculo do imposto pode ser diferente. Sem o strategy pattern, você precisaria modificar o código da classe para lidar com cada país individualmente.
Mas com o strategy pattern, você pode criar uma interface de estratégia para representar cada país e implementar a estratégia correta para cada país. Dessa forma, se você precisar adicionar ou remover um país, você pode fazê-lo sem precisar modificar o código da classe.
Em resumo, o Open-Closed Principle é um princípio importante que ajuda a produzir código de alta qualidade e fácil de manter. O strategy pattern é uma técnica de design de software que ajuda a implementar esse princípio, tornando o código mais flexível e escalável.
L(Liskov Substitution Principle)
🤔 Calma, seu conceito é mais simples que o nome.
O Liskov Substitution Principle é um princípio que diz que uma subclasse deve ser capaz de ser usada como sua superclasse sem causar problemas no programa. Isso significa que você pode trocar uma classe por outra, desde que a nova classe mantenha as mesmas características e comportamentos da classe original. Em outras palavras, a subclasse deve ser “substituível” pela superclasse.
Imagine que você tem uma classe “Pessoa” e uma subclasse “Super-Herói”. Ambos são pessoas, mas o super-herói tem habilidades extras, certo? Agora, imagine que você tem uma função que espera uma “Pessoa” como entrada. Se você segue o Liskov Substitution Principle, você pode passar um “Super-Herói” para essa função sem que isso cause problemas, pois ele ainda é uma “Pessoa”, só com habilidades extras. É como se a função não soubesse que está trabalhando com um super-herói, mas ainda assim tudo funciona perfeitamente. Então, o Liskov Substitution Principle permite que você use super-heróis para resolver problemas de pessoas comuns, sem que isso altere o resultado esperado.
I(Interface segregation Principle)
Imagine que você tem um grupo de amigos que adoram ir a festas juntos. Alguns deles gostam de dançar, outros gostam de cantar, outros gostam de jogar jogos, etc.
Mas e se a festa só oferece uma atividade para todos? Alguns amigos ficariam entediados, certo?
É aí que entra o princípio de Segregação de Interfaces (Interface Segregation Principle — ISP) do SOLID. Ele diz: “Não force seus amigos a fazerem algo que eles não gostam.”
Em programação, a ideia é a mesma. Não force uma classe a implementar métodos que ela não precisa. Em vez disso, crie interfaces mais específicas para atender às necessidades específicas das classes. Isso garante que as classes não fiquem sobrecarregadas com métodos desnecessários e que a modularidade do seu código seja preservada.
Por exemplo, em vez de ter uma interface genérica que abranja vários métodos, é melhor ter várias interfaces mais específicas para cada tarefa. Assim, as classes que precisam realizar tarefas específicas podem implementar as interfaces apropriadas, sem ser obrigadas a implementar métodos que não precisam.
Em resumo, o ISP garante que as interfaces sejam pequenas e específicas, tornando o código mais modular e fácil de manter. Assim, todos os amigos na festa podem fazer o que realmente gostam, sem serem forçados a fazer algo que não gostam. E é assim que você garante que todos estejam felizes e divertidos!
D(Dependency Inversion Principle)
Opa, não confunda com injeção de dependência!
Módulos de alto nível não devem depender de módulos de baixo nível; ambos devem depender de abstrações.
Quando você está construindo algo com legos, você sempre coloca as peças grandes e fortes no fundo para que sejam a base sólida da sua construção.
Da mesma forma, em programação, você não quer que as classes importantes dependam diretamente de outras classes menos importantes. Em vez disso, você quer que as classes importantes dependam de uma abstração, assim como as peças grandes e fortes dependem da base sólida.
Isso significa que você pode mudar as peças menores sem prejudicar as peças grandes, e isso garante que o seu código seja flexível e fácil de manter. É como ter uma casa construída sobre uma base sólida!
Conclusão:
Em resumo, o SOLID é uma coleção de princípios de design de software que ajudam a produzir código de alta qualidade e facilmente manutenível. Aplicando esses princípios ao seu código, você pode criar aplicações robustas e escaláveis que serão fáceis de manter no futuro.
