SOLID: O Guia Definitivo Para Evitar Crises de Choro na Programação

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 o seu código legado possa ignorar. Vamos lá!

S – Single Responsibility Principle (Responsabilidade Única)

O lema: "Não seja o cara que faz tudo."

Pense naquela função que quer ser a Rainha Elizabeth: ela quer viver para sempre e fazer de tudo. Ela calcula imposto, manda e-mail, busca dados na API, faz o café e ainda tenta resolver o aquecimento global.

Amigo(a), funções com muita responsabilidade envelhecem mal!

• Na prática: Uma função, uma única tarefa. Seu código deve ser como aquele personal trainer que grita "foco no objetivo!". O resultado? Menos peso na manutenção e, claro, menos bugs.

O – Open/Closed Principle (Aberto/Fechado)

O lema: "Aberto para novas ideias, fechado para bagunça."

Seu código deve ser como um bom relacionamento: precisa estar aberto para novas funcionalidades (extensão), mas fechado para alterações perigosas naquilo que já funciona.

Pense no seu código como um guarda-roupa: você pode sempre adicionar novas peças, mas não precisa desmontar o móvel inteiro para incluir uma camisa nova. Modificações diretas no código original são como a sogra querendo redecorar sua sala: mexe demais e ninguém mais reconhece o lugar!

L – Liskov Substitution Principle (Substituição de Liskov)

O lema: "Não quebre o contrato (nem o cliente)."

Se você está num restaurante e pede uma lasanha, você espera lasanha, certo? Agora imagine se o garçom trouxesse uma sopa de alface porque ele acha que "é mais saudável".

No código, é a mesma coisa. Se você substitui uma classe por uma subclasse, ela precisa se comportar exatamente como a classe base. Se algo pode ser substituído, mas quebra o resto do sistema, você fez errado. Nada de lasanha virando sopa. Faça as coisas previsíveis, como a pizza de sexta-feira.

I – Interface Segregation Principle (Segregação de Interfaces)

O lema: "Não me dê o que não pedi!"

Sabe aquele atendente de fast-food que pergunta "Quer batata, refrigerante, molho especial, talheres de ouro e uma sobremesa?" quando você só queria um café? Interfaces também não podem ser intrometidas!

Suas funções não devem forçar outras partes do código a lidar com coisas que elas não vão usar. Se a função só precisa de café, não force ela a carregar talheres de ouro também. Isso só deixa tudo mais pesado e confuso.

D – Dependency Inversion Principle (Inversão de Dependência)

O lema: "Dependa de abstrações, não de implementações."

Esse é 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 (abstrações) e não da classe concreta. Assim, quando a moda do momento mudar (e ela sempre muda), você troca o figurino sem ter que refazer o guarda-roupa inteiro.

Conclusão: Viva sem o "Choro das 3 da manhã"

O SOLID é a espinha dorsal da programação bem-feita — ou, pelo menos, daquela programação que não vai te fazer chorar às 3 da manhã quando seu código quebrar em produção.

Leve essas regras a sério (ou quase), aplique com bom senso e veja sua vida — e a dos seus reviewers — ficar muito mais leve.