Princípios SOLID
Os cinco princípios de design orientado a objetos, um de cada vez: o problema que cada um resolve, quando aplicar e quando a aplicação atrapalha mais do que ajuda. Cada post tem exemplo executável em TypeScript, Python e Java. A trilha vai do SRP ao DIP e fecha com a escolha entre compor e herdar.
- 01
Responsabilidade única (SRP)
Uma classe, uma responsabilidade: por que uma classe que faz tudo é difícil de mudar, o trade-off entre extrair e deixar onde está, e como refatorar uma que já cresceu demais.
- 02
Aberto/fechado (OCP)
Estender em vez de editar: por que cada pedido novo vira um if na mesma classe, herança versus injeção como ponto de extensão, e o custo escondido de contratos que devolvem menos do que já sabem.
- 03
Substituição de Liskov (LSP)
Subtipo é subconjunto: o que a classe pai promete precisa ser verdade para todo filho, por que quase toda violação se conserta em cima e não na subclasse, e o critério para saber o que pertence ao contrato.
- 04
Segregação de interfaces (ISP)
Contrato inchado obriga quem implementa a assinar o que não cumpre: o caso da Xerox que deu origem ao princípio, o critério de separar por contexto e por ganho, e quando fatiar é melhor que generalizar.
- 05
Inversão de dependência (DIP)
Depender de contrato, não de implementação: por que o DIP é o que faz as camadas da Clean Architecture existirem de verdade, o que exatamente é invertido, e por que injeção de dependência sozinha não é DIP.
- 06
Fechamento: composição vs. herança
A decisão que atravessa os cinco princípios: extends entrega reúso e identidade no mesmo pacote, capacidade se resolve compondo, identidade se resolve com contrato, e por que herdar cobra uma promessa que compor não cobra.