Introdução
Se você desenvolve software orientado a objetos, já deve ter ouvido falar dos princípios SOLID. Criados para tornar o código mais legível, reutilizável e fácil de manter, esses princípios se tornaram um pilar da engenharia de software moderna — especialmente em projetos complexos ou com equipes grandes.
Neste guia, vamos explorar o que é o SOLID, o significado de cada letra, exemplos práticos e quando aplicar esses conceitos no seu dia a dia como desenvolvedor.
O que é SOLID?
SOLID é um acrônimo para cinco princípios propostos por Robert C. Martin (Uncle Bob) com base em ideias de Bertrand Meyer. Esses princípios guiam a criação de software orientado a objetos com foco em design limpo, desacoplamento e manutenção fácil.
O termo é formado por:
- S – Single Responsibility Principle (Responsabilidade Única)
- O – Open/Closed Principle (Aberto/Fechado)
- L – Liskov Substitution Principle (Substituição de Liskov)
- I – Interface Segregation Principle (Segregação de Interfaces)
- D – Dependency Inversion Principle (Inversão de Dependência)
🔹 S — Single Responsibility Principle
“Uma classe deve ter apenas um motivo para mudar.”
Esse princípio sugere que uma classe deve ter uma única responsabilidade — ou seja, ela deve fazer apenas uma coisa e fazer bem.
Exemplo ruim:
class Usuario {
criarUsuario() {}
salvarNoBanco() {}
enviarEmailBoasVindas() {}
}
Exemplo bom:
class Usuario {}
class UsuarioRepository {
salvar(usuario: Usuario) {}
}
class EmailService {
enviarBoasVindas(usuario: Usuario) {}
}
Separando responsabilidades, o código fica mais testável e modular.
🔸 O — Open/Closed Principle
“Entidades de software devem estar abertas para extensão, mas fechadas para modificação.”
Significa que, ao precisar adicionar uma nova funcionalidade, você deve estender o comportamento existente, não alterá-lo diretamente.
Exemplo:
interface CalculadoraSalario {
calcular(): number;
}
class CLT implements CalculadoraSalario {
calcular() { return 3000 - 500; }
}
class PJ implements CalculadoraSalario {
calcular() { return 4000; }
}
function exibirSalario(c: CalculadoraSalario) {
return c.calcular();
}
Se amanhã surgir um novo tipo de contrato, basta criar uma nova classe — sem alterar as existentes.
🔹 L — Liskov Substitution Principle
“Objetos de uma superclasse devem ser substituíveis por objetos de suas subclasses.”
Esse princípio, proposto por Barbara Liskov, reforça que subclasses devem manter o comportamento esperado da classe base.
Exemplo de violação:
class Ave {
voar() {}
}
class Pinguim extends Ave {
voar() { throw new Error("Pinguins não voam"); }
}
Melhor abordagem:
class Ave {}
class AveVoadora extends Ave {
voar() {}
}
class Pinguim extends Ave {}
Evite subclasses que quebrem o comportamento da base.
🔸 I — Interface Segregation Principle
“Uma classe não deve ser forçada a implementar métodos que não usa.”
Evite interfaces “inchadas” com métodos irrelevantes para algumas implementações.
Exemplo de interface ruim:
interface Funcionario {
baterPonto();
atenderCliente();
programar();
}
Melhor:
interface Atendimento {
atenderCliente();
}
interface Desenvolvimento {
programar();
}
Cada classe implementa apenas o que faz sentido para sua função.
🔹 D — Dependency Inversion Principle
“Dependa de abstrações, não de implementações concretas.”
Em vez de uma classe usar diretamente outra classe concreta, ela deve depender de interfaces ou abstrações, o que facilita testes e flexibilidade.
Exemplo:
interface EmailService {
enviar(): void;
}
class EnviadorReal implements EmailService {
enviar() { console.log("Enviado de verdade"); }
}
class Notificacao {
constructor(private emailService: EmailService) {}
notificar() { this.emailService.enviar(); }
}
Com isso, é fácil trocar EnviadorReal por um mock nos testes.
Quando usar SOLID?
Você não precisa aplicar todos os princípios SOLID em todo código, mas eles são ótimos guias para:
- Projetos grandes e com múltiplas camadas
- Equipes que compartilham código
- Softwares com testes automatizados
- APIs públicas ou SDKs
Em projetos pequenos ou MVPs, você pode simplificar — mas sempre que notar código difícil de manter, vale revisar com base no SOLID.
Conclusão
Os princípios SOLID ajudam você a escrever código mais limpo, testável e escalável. Eles exigem um pouco mais de atenção no início, mas reduzem o custo de manutenção no longo prazo.
Aplicar SOLID não é uma obrigação — é uma escolha consciente para construir software de qualidade profissional. Se você trabalha com orientação a objetos, aprender e aplicar esses princípios vai transformar sua forma de programar.
📚 Referências
- Robert C. Martin (Uncle Bob) – Clean Architecture e Agile Software Development
https://clean-architecture.io - Barbara Liskov – Original definition of Liskov Substitution Principle
https://en.wikipedia.org/wiki/Liskov_substitution_principle - Martin Fowler – Design Principles and Patterns
https://martinfowler.com/articles/design-principles.html - SOLID Principles Explained – Devopedia
https://devopedia.org/solid-principles - Refactoring Guru – SOLID Principles
https://refactoring.guru/design-patterns/principles
