Principios SOLID — De cero a hero

SOLID es un acrónimo de cinco principios de diseño orientado a objetos popularizados por Robert C. Martin (Uncle Bob) a comienzos de los 2000. No son reglas ceremoniales ni patrones que se copian y pegan: son heurísticas para gestionar dependencias entre las piezas de tu software, de modo que el código resista el cambio en lugar de romperse con cada nuevo requisito.

La promesa de SOLID es concreta. Un diseño que respeta estos principios es más fácil de extender (agregás comportamiento sin tocar lo que ya funciona), más fácil de testear (podés aislar cada pieza) y más fácil de entender (cada clase tiene un motivo claro para existir). Un diseño que los ignora tiende a la rigidez (cambiar algo obliga a cambiar mil cosas), la fragilidad (tocás A y se rompe B) y el acoplamiento que convierte cualquier refactor en una aventura de riesgo.

Este curso recorre los cinco principios en profundidad, cada uno con su definición formal, el code smell que ataca, un ejemplo malo real, el refactor paso a paso y diagramas para fijar el modelo mental. Todos los ejemplos están en TypeScript.

Los cinco principios de un vistazo

mindmap
  root((SOLID))
    S["SRP<br/>Responsabilidad Única"]
      Una clase, una razón para cambiar
    O["OCP<br/>Abierto/Cerrado"]
      Extender sin modificar
    L["LSP<br/>Sustitución de Liskov"]
      Los subtipos deben ser sustituibles
    I["ISP<br/>Segregación de Interfaces"]
      Interfaces pequeñas y específicas
    D["DIP<br/>Inversión de Dependencias"]
      Depender de abstracciones

Índice de capítulos

#	Capítulo	Qué aprenderás
1	Introducción a SOLID	Historia y origen (Uncle Bob), qué problema resuelve cada principio, los code smells del diseño rígido (rigidez, fragilidad, inmovilidad, viscosidad) y los conceptos base: cohesión y acoplamiento.
2	SRP: Principio de Responsabilidad Única	Una clase debe tener una sola razón para cambiar. Cómo detectar responsabilidades mezcladas, el concepto de actor, y separar lógica de negocio, persistencia y presentación.
3	OCP: Principio Abierto/Cerrado	El software debe estar abierto a la extensión pero cerrado a la modificación. Eliminar los switch que crecen sin fin usando polimorfismo y el patrón Strategy.
4	LSP: Principio de Sustitución de Liskov	Los subtipos deben ser sustituibles por sus tipos base sin romper el programa. El clásico problema Cuadrado/Rectángulo, precondiciones y postcondiciones.
5	ISP: Principio de Segregación de Interfaces	Ningún cliente debería depender de métodos que no usa. Partir interfaces “gordas” en contratos pequeños y cohesivos.
6	DIP: Principio de Inversión de Dependencias	Los módulos de alto nivel no deben depender de los de bajo nivel: ambos dependen de abstracciones. La base de la inyección de dependencias.
7	SOLID en conjunto: refactor de un caso real	Cómo los cinco principios se refuerzan entre sí. Refactor completo de un módulo que viola todo, aplicando los principios uno tras otro.
8	SOLID y la arquitectura hexagonal	Por qué DIP e ISP son el motor de los puertos y adaptadores. Cómo SOLID conduce naturalmente a una arquitectura limpia.
9	Anti-patrones y cuándo NO aplicar SOLID	El otro lado: sobre-ingeniería, abstracciones prematuras, el acrónimo STUPID y cómo evitar convertir SOLID en dogma.
10	SOLID y testing	Cómo cada principio hace el código más testeable: dobles de prueba, inyección de dependencias y por qué el código SOLID casi se testea solo.

¿Para quién es este curso?

Para cualquier persona que escriba código orientado a objetos y quiera que ese código sobreviva al paso del tiempo y los requisitos. Necesitás conocimientos básicos de TypeScript (clases, interfaces, tipos) y haber sentido, al menos una vez, el dolor de tocar una parte del sistema y romper otra. Ese dolor es exactamente lo que SOLID viene a curar.

Cómo usar el curso

Los capítulos están pensados para leerse en orden: la introducción fija el vocabulario (cohesión, acoplamiento, code smells) que usaremos en todos los demás, y cada principio construye sobre el anterior. Si ya conocés la teoría y venís por los ejemplos, cada capítulo de principio es autocontenido y podés saltar directo al que te interese.

Consejo: no leas SOLID como una lista de mandamientos. Leelo como cinco preguntas que te hacés frente al código: ¿esta clase tiene una sola razón para cambiar? ¿puedo extender esto sin tocarlo? ¿este subtipo miente sobre su contrato? ¿esta interfaz obliga a implementar cosas de más? ¿estoy dependiendo de un detalle o de una abstracción?

Empecemos por el principio: Introducción a SOLID →