Ah, o famoso SOLID! Se você já ouviu falar, provavelmente é um programador que vive no caos da refatoração e já cansou de receber aquele olhar fulminante do code reviewer. Não se preocupe, vou explicar SOLID de uma maneira que nem seu cachorro (ou seu código legado) possa ignorar. Vamos lá!

S – “S” de Responsabilidade Única, ou… O “Não-Seja-O-Cara-Que-Faz-Tudo”

Pense numa função que quer ser a Rainha Elizabeth: ela quer viver para sempre! Essas funções fazem tudo — calculam imposto, mandam e-mail, buscam dados na API, fazem café… Você já entendeu. Mas, amigo(a), funções com muita responsabilidade envelhecem mal!

Uma função, uma responsabilidade. Seu código é como aquele personal trainer que grita “foco no objetivo!” enquanto você tenta correr na esteira. O resultado? Menos peso… em bugs!

O – Aberto/Fechado: Aberto Para Extensão, Fechado Para Modificação (Tipo uma Sogra)

Seu código deve ser como… uma boa relação de casamento (ou pelo menos como dizem por aí). Ele precisa estar aberto para novas ideias, mas fechado para mudanças ruins. Pense na sua função como um guarda-roupa: você pode sempre adicionar novas peças de roupa, mas não precisa refazer todo o guarda-roupa para incluir uma camisa nova.

Modificações diretas no código são como a sogra querendo redecorar sua sala: mexe demais e ninguém mais reconhece o lugar!

L – Substituição de Liskov: Não Quebre o Contrato (Nem o Código)

Se você está num restaurante e pede uma lasanha, espera lasanha, certo? Agora imagine se o garçom trouxesse sopa porque ele acha que “é mais saudável”. No código, é a mesma coisa! Se você substitui uma função ou uma classe, ela deve fazer o que promete. Nada de surpresas!

Aqui está a dica: se algo pode ser substituído, mas quebra o resto do código, você fez errado. Então, nada de lasanha virando sopa. Faça as coisas previsíveis, como a pizza de sexta.

I – Segregação de Interfaces: Não Me Dê o Que Não Pedi!

Sabe aquele atendente que pergunta “Quer batata, refrigerante, molho especial, talheres de ouro?” quando você só quer um café? Interfaces também não podem ser intrometidas! Suas funções e classes não devem forçar outras partes do código a lidarem com coisas que não pediram.

Se a função só precisa de café, não a force a carregar talheres de ouro também. Isso só deixa tudo mais pesado (e confuso)!

D – Dependência… de Abstrações! (Não Implementações)

Esse aqui é o último e talvez o mais filosófico (tente não dormir): seu código deve ser como um bom ninja — depender de coisas que podem mudar facilmente. Não seja aquele programador que escreve código como se estivesse tatuando o nome da namorada no braço na primeira semana de namoro.

Dependa de interfaces e não da implementação exata. Assim, quando a moda do momento mudar, você troca o figurino sem ter que refazer o guarda-roupa inteiro (lembre-se do exemplo da sogra!).

Conclusão: O SOLID é a espinha dorsal da programação bem-feita… ou pelo menos da programação que não vai te fazer chorar às 3 da manhã quando seu código quebrar na produção. Leve essas regras a sério (ou quase) e veja sua vida — e a dos seus reviewers — ficarem muito mais leves.