SOLID — Princípios que todo dev deveria conhecer

SOLID é um acrônimo para cinco princípios de design orientado a objetos que, juntos, tornam o código mais fácil de manter, estender e testar. Eles não são regras rígidas — são guias para tomar decisões melhores de arquitetura.

S — Single Responsibility

Uma classe deve ter um único motivo para mudar. God Classes acumulam responsabilidades e, com elas, acumulam bugs. Quanto mais responsabilidades, mais difícil isolar onde está o problema.

class EmailService    { send() {} }
class UserRepository { save() {} }
// separados. claros. testáveis.

O — Open/Closed

Aberto para extensão, fechado para modificação. O problema do if/else infinito: a cada nova regra, você abre o mesmo arquivo e arrisca quebrar o que já funciona. Com OCP, você adiciona o Pix sem tocar no código do Cartão de Crédito.

class PixPayment  implements Payment {}
class CardPayment implements Payment {}
// Payment nunca muda. você só adiciona.

L — Liskov Substitution

Subclasses devem honrar o contrato da classe pai. Sobrescrever métodos de forma inesperada gera erros silenciosos em runtime. Se a classe pai promete um comportamento, a filha entrega o mesmo — ou mais.

function process(payment: Payment) {}
process(new PixPayment())  // ✓
process(new CardPayment()) // ✓

I — Interface Segregation

Interfaces pequenas, sem bagagem desnecessária. Fat interfaces geram acoplamento falso — você implementa métodos que não usa só para satisfazer um contrato gigante. Granularidade é poder.

interface Printable { print() }
interface Saveable  { save() }
// não: interface GodInterface { print(); save(); send(); }

D — Dependency Inversion

Dependa de abstrações, não de implementações. Quando o repositório muda, a regra de negócio não deve quebrar junto. Sua lógica depende de uma interface — o banco, a API, o mock são detalhes.

class OrderService {
  constructor(private repo: IOrderRepo) {}
}
// repo pode ser Postgres, Mongo ou Mock
// a regra não sabe e não precisa saber.

SOLID não é sobre seguir regras à risca — é sobre construir sistemas onde adicionar uma feature não significa reescrever o que já funciona. Quando você internaliza esses princípios, a arquitetura começa a emergir naturalmente.

• S: Uma classe, um motivo para mudar
• O: Extensível sem modificar o núcleo
• L: Subclasses honram o contrato da pai
• I: Interfaces pequenas e focadas
• D: Dependa de abstrações, não de concreto