Código sustentável não é o código com mais abstrações. É aquele que uma equipe consegue entender, alterar e testar sem transformar cada nova regra em uma sequência de efeitos colaterais.
Os princípios SOLID ajudam nesse objetivo. Eles não oferecem uma arquitetura pronta, mas orientam decisões sobre responsabilidades, dependências e contratos. Quando usados com contexto, tornam mudanças mais locais e deixam explícito o que cada parte do sistema pode fazer.
De onde vem o SOLID?
Os cinco princípios foram apresentados e discutidos por Robert C. Martin ao longo dos anos 1990 e 2000. O acrônimo SOLID foi popularizado depois por Michael Feathers como uma forma simples de reunir essas ideias.
Embora tenham surgido em discussões sobre orientação a objetos, os princípios não dependem de uma linguagem específica. Em Node.js com TypeScript, eles aparecem no desenho de classes, interfaces, funções e módulos.
SOLID significa:
SRP - Single Responsibility Principle
O princípio da responsabilidade única diz que um módulo deve ter uma razão principal para mudar. Uma classe que calcula uma fatura, gera um PDF, salva dados e envia e-mail reúne decisões de áreas diferentes.
Separar essas responsabilidades reduz o impacto das mudanças. Alterar o formato do documento não deveria colocar em risco o cálculo financeiro.
OCP - Open/Closed Principle
O princípio aberto/fechado orienta que um componente esteja aberto para extensão e fechado para modificação. A ideia não é proibir edições, mas permitir novas variações sem reescrever um fluxo estável.
Um processador de pagamentos, por exemplo, pode depender de um contrato comum. Assim, adicionar outro provedor significa criar uma implementação, não aumentar uma cadeia de condicionais.
LSP - Liskov Substitution Principle
O princípio da substituição de Liskov afirma que uma implementação deve poder ocupar o lugar do contrato que representa sem surpreender quem a utiliza.
Se um repositório promete salvar um registro e uma implementação ignora silenciosamente a operação, o tipo pode até compilar, mas o contrato foi quebrado. LSP trata do comportamento, não apenas da assinatura dos métodos.
ISP - Interface Segregation Principle
O princípio da segregação de interfaces recomenda contratos pequenos e coesos. Um consumidor não deveria implementar ou receber operações das quais não precisa.
Separar leitura, gravação e remoção de arquivos, por exemplo, permite que cada serviço declare apenas as capacidades que realmente utiliza.
DIP - Dependency Inversion Principle
O princípio da inversão de dependência orienta que regras importantes não dependam diretamente de detalhes de infraestrutura. Tanto o fluxo de negócio quanto esses detalhes passam a depender de abstrações.
Um caso de uso de cadastro pode conhecer um contrato de repositório, mas não precisa saber se os dados serão persistidos em arquivo, memória ou banco de dados.
Benefícios
Uma aplicação orientada por esses princípios tende a ganhar:
- mudanças mais localizadas;
- contratos mais claros;
- testes com menos dependências externas;
- implementações substituíveis;
- menor risco ao adicionar novas regras;
- vocabulário comum para decisões de design.
Esses benefícios não vêm da quantidade de interfaces. Eles aparecem quando as abstrações acompanham variações reais do domínio.
Fechamento
SOLID é um conjunto de critérios para pensar sobre mudança. Os cinco princípios funcionam melhor juntos, mas não precisam ser aplicados todos ao mesmo tempo.
O objetivo não é produzir a arquitetura mais sofisticada. É manter as decisões importantes visíveis e permitir que o sistema evolua sem cobrar um preço desproporcional a cada alteração.
Série SOLID
Este artigo faz parte de uma série de artigos: