SOLID: um conceito básico que muitos devs esquecem

Você é do time dos que acreditam que pessoas desenvolvedoras mais experientes só precisam focar em se atualizar? Hoje vamos mostrar para você que nem sempre isso é verdade, viu? O SOLID é um daqueles conceitos mais básicos que acabam fazendo parte lá do comecinho da carreira de quem desenvolve, mas que acabam sendo esquecidos no meio do trajeto. Porém, apesar de ser um conhecimento mais simples, de certa forma, ele faz toda a diferença na forma de pensar a programação orientada a objetos (também chamada de POO).

O que é SOLID e porque ele é importante?

SOLID nada mais é do que um acrônimo que reúne os principais princípios da programação orientada a objetos. Esses princípios, por sua vez, acabam guiando a pessoa desenvolvedora em direção a códigos muito mais maduros, flexíveis e reaproveitáveis. E isso é superimportante para quem quer se destacar na área, né?

E quais são os princípios do SOLID?

Cada letra do acrônimo SOLID representa um princípio em inglês, sendo eles:

1. single responsibility principle (SRP), ou seja, princípio da responsabilidade única;
2. open/closed principle (OCP), ou seja, princípio aberto-fechado;
3. Liskov substitution principle (LSP), ou seja, princípio da substituição de Liskov;
4. interface segregation principle (ISP), ou seja, princípio da segregação de interface;
5. dependency inversion principle (DIP), ou seja, princípio da inversão de dependência.

Na prática, é possível falar durante horas sobre cada um desses princípios, mas por aqui faremos um mega resumo de cada um deles e das razões pelas quais eles são tão importantes para a POO. Vamos lá dar uma olhada em cada um deles?

SRP, o princípio da responsabilidade única

Se você já ouviu aquela clássica frase “quem faz tudo não faz nada”, vai ver muitas similaridades entre esse pensamento e o princípio da responsabilidade única. Isso porque o SRP diz que uma classe ou módulo deve ser responsável por apenas uma funcionalidade do software. Além disso, deve desempenhar muito bem essa função.

Esse princípio não surge à toa, já que, quando aplicado, torna o processo de testes mais rápido, permite um acoplamento menor e, exatamente por ter poucas dependências, garante um código mais organizado e maleável.

OCP, o princípio aberto-fechado

Nesse segundo princípio do SOLID, temos que entidades devem estar abertas à expansão, enquanto seguem fechadas para a modificação. Isso significa que módulos, classes, funções e outras entidades podem receber novos comportamentos, mas não devem permitir a modificação do seu código para isso acontecer.

Adicionar comportamentos sem que o código mude pode parecer complexo, né? Mas saiba que, para isso, basta usar o conceito de herança ou o polimorfismo. Acredite: a longo prazo, adquirir esses aprendizados compensa! Afinal, a aplicação desse princípio reduz as chances de erro ao longo do desenvolvimento — sonho de toda pessoa desenvolvedora, não é mesmo?

LSP, o princípio da substituição de Liskov

É aqui na letra L que o SOLID acaba ficando um pouco mais complicado. A LSP diz que classes derivadas precisam estar abertas a serem substituídas por classes bases sem que o programa tenha seu funcionamento interrompido. Um exemplo que quebraria esse princípio, é implementar um método que não serve para nada. E qual pessoa desenvolvedora nunca fez isso lá no comecinho da carreira?

Esse princípio, por si só, não traz muitas vantagens, mas ele impacta bastante na aplicação do OCP e do ISP. Por isso, vale ter um carinho extra na hora de se aprofundar e aplicar esse princípio, viu?

ISP, o princípio da segregação de interface

O ISP diz que usar várias interfaces específicas é muito melhor do que usar uma única interface para tudo — e não faltam razões para isso! Nesse contexto, fazer uma única interface faz com que classes implementem métodos que não têm nada a ver consigo, isso para citar apenas uma possibilidade. Inevitavelmente isso também acaba quebrando o princípio do SRP. Ou seja, é melhor evitar!

Por outro lado, quando esse princípio é aplicado da forma certa, a pessoa desenvolvedora consegue desviar de vários erros que iam acabar com o funcionamento e a UX do seu projeto.

DIP, o princípio da inversão de dependência

Por fim, o SOLID termina com o princípio DIP. Ele finaliza o acrônimo com uma orientação bastante importante: faça com que os módulos do seu software, sejam eles de alto ou baixo nível, dependam somente de abstrações. Qual a vantagem disso? Favorecer a reusabilidade do código!

Tendo em vista isso tudo, colocar esse princípio em prática é apenas possível através do uso do padrão de inversão de dependência, sendo um tema um pouco extenso e que vale a pena adicionar à sua lista de estudos se você ainda não conhecer ele muito bem. Porém, vale só um último lembrete: cuidado para não confundir esse tema com injeção de dependência, hein?

E aí, conseguiu relembrar ou, até, aprender um pouco mais sobre os princípios que o SOLID engloba? Apesar desse conceito ser originalmente aplicado ao desenvolvimento de softwares, ele traz muitos aprendizados que também têm tudo a ver com outras vertentes de desenvolvimento.

Tanto é que, aqui na Mosaico, estamos repletos de oportunidades para quem quer colocar esse aprendizado em prática. Então inscreva-se para ficar sabendo quais são elas.