SOLID na prática: o que esses princípios significam para o custo de manutenção

Por que SOLID importa para o negócio

SOLID não é sobre fazer código "bonito" — é sobre fazer código que pode ser modificado sem riscos. Cada princípio resolve um problema específico de custo de manutenção. Violá-los sistematicamente não causa problema no primeiro ano — causa problema quando o produto precisa mudar com velocidade.

Os cinco princípios e seu impacto prático

• Single Responsibility — cada classe tem um único motivo para mudar. Violação: a mudança numa funcionalidade quebra outra não relacionada.
• Open/Closed — aberto para extensão, fechado para modificação. Violação: cada nova feature exige modificar código existente e testado.
• Liskov Substitution — subtipos devem ser substituíveis por seus tipos base. Violação: código cheio de type checks e condicionais de tipo.
• Interface Segregation — não force implementadores a depender de métodos que não usam. Violação: classes que implementam interfaces enormes com metade dos métodos vazia.
• Dependency Inversion — dependa de abstrações, não de concretizações. Violação: código de negócio diretamente acoplado ao banco de dados ou framework.

Quando não aplicar SOLID

SOLID tem custo de abstração. Para scripts, protótipos e código com vida útil curta, o overhead de seguir todos os princípios pode não se justificar. O julgamento de quando aplicar é parte da maturidade técnica.