SOLID — Os 5 princípios de design
Baixar PDFIntrodução aos princípios SOLID em TypeScript — o que são, por que importam e como navegar nas 5 páginas dedicadas.
SOLID em TypeScript
SOLID é um acrônimo criado por Michael Feathers (2000) a partir dos princípios de Robert C. Martin (Uncle Bob). São 5 regras de design orientado a objetos que, quando aplicadas, produzem código que é fácil de entender, testar e modificar.
O que significa SOLID?
| Letra | Princípio | Em uma frase |
|---|---|---|
| S | Single Responsibility | Uma classe deve ter apenas um motivo para mudar |
| O | Open/Closed | Aberta para extensão, fechada para modificação |
| L | Liskov Substitution | Subtipos devem ser substituíveis por seus tipos base |
| I | Interface Segregation | Prefira interfaces pequenas e específicas |
| D | Dependency Inversion | Dependa de abstrações, não de implementações |
Analogia do dia a dia
Imagine um restaurante:
- S — O cozinheiro cozinha, o garçom atende, o caixa cobra. Se o cozinheiro também tivesse que atender e cobrar, uma mudança no cardápio afetaria o atendimento.
- O — O cardápio pode receber pratos novos sem precisar reescrever o cardápio inteiro.
- L — Se o cardádio diz "prato vegetariano", um prato que usa caldo de carne não deveria estar nessa categoria.
- I — O garçom precisa saber o que serve, mas não precisa saber a receita. O cozinheiro precisa saber a receita, mas não precisa saber cobrar.
- D — O gerente dá ordens (abstração), não importa se é o João ou a Maria executando.
Por que importa em TypeScript?
TypeScript não é apenas JavaScript com tipos — ele dá ferramentas concretas para aplicar SOLID:
- Interfaces → base para I e D
- Generics → permitem L sem duplicação
- Type narrowing → ajuda com S ao separar responsabilidades de tipo
satisfies→ garante O sem perder inferência
Estude cada princípio
S — Single Responsibility
Uma classe, uma razão para mudar.
O — Open/Closed
Novas funcionalidades sem reescrever código existente.
L — Liskov Substitution
Um pato voa, mas um pato de borracha não deveria herdar de Pato.
I — Interface Segregation
Ninguém deveria ser forçado a depender de métodos que não usa.
D — Dependency Inversion
Módulos de alto nível não devem depender de módulos de baixo nível.
Referências
DRY, KISS e YAGNI
Três lembretes que evitam os maiores crimes contra a legibilidade — Don't Repeat Yourself, Keep It Simple, You Aren't Gonna Need It.
S — Single Responsibility Principle
Uma classe, uma função, um módulo — uma única razão para mudar. Exemplos full-stack em React, Next.js, NestJS e Express.