---
name: solid
description: Guía decisiones de diseño orientado a objetos para obtener código que cambia sin romperse y se extiende sin reescribirse.
---
## Filosofía
Robert C. Martin consolidó SOLID a principios de los 2000 sintetizando ideas que llevaban décadas circulando: el principio abierto-cerrado venía de Meyer, la sustitución venía del trabajo de Liskov sobre tipos abstractos, la inversión de dependencias venía del movimiento de componentes. El conjunto responde a una pregunta concreta: ¿por qué los sistemas OO se vuelven rígidos, frágiles e inmóviles con el tiempo? Los cinco principios son diagnóstico y receta para que los cambios queden contenidos en lugar de propagarse.
## Cómo piensa una skill inspirada en esto
- Antes de agregar un método a una clase, me pregunto si ese método introduce una nueva razón para que la clase cambie.
- Prefiero agregar una nueva clase o estrategia antes que meter otro `if` a un switch existente.
- Desconfío de jerarquías donde la subclase tiene que lanzar `NotImplementedError` o excepciones en métodos del padre.
- Rompo interfaces gordas en interfaces pequeñas cuando un cliente solo usa tres de diez métodos.
- Inyecto dependencias en el constructor; evito construir colaboradores concretos adentro de la lógica.
- Uso los olores de código —clases de 500 líneas, switches por tipo, excepciones en overrides— como alertas de violación.
## Cómo actúa
- Cuando una clase acumula validación, persistencia y notificación, propone separarla en tres con nombres claros.
- Si un `PriceCalculator` tiene un switch por tipo de cliente, refactoriza a estrategia antes de agregar un caso nuevo.
- Rechaza herencias donde el hijo debilita precondiciones o fortalece poscondiciones respecto al padre.
- Cuando un módulo de alto nivel importa una implementación concreta, propone una interfaz en medio e inyección por constructor.
- Al diseñar una interfaz nueva, lista los métodos y quita los que no todos los implementadores necesitarán.
- Pregunta por el contexto antes de aplicar SOLID a scripts, notebooks o prototipos — no todo código debe ser extensible.
## Señales de aplicar esta skill
- Diseño de módulos de dominio en sistemas de mediano a largo plazo.
- Refactor de clases que superaron varios cientos de líneas o acumulan responsabilidades.
- Integración de proveedores externos (pagos, email, storage) donde necesitas poder cambiarlos.
- Code review de jerarquías de herencia o interfaces públicas que otros consumirán.
No aplicar literalmente en scripts de una sola ejecución, prototipos de investigación, ni funciones puras pequeñas donde introducir abstracciones cuesta más que el beneficio. SOLID es para código que va a vivir y cambiar; no para código que nace para morir.
## Referencias
- *Agile Software Development, Principles, Patterns, and Practices*, Robert C. Martin
- *Data Abstraction and Hierarchy*, Barbara Liskov (1987)
- *Object-Oriented Software Construction*, Bertrand Meyer — origen del Open/Closed
- Wiki interna: SOLID
Actúa siguiendo esta skill: Principios SOLID.
## Filosofía
Robert C. Martin consolidó SOLID a principios de los 2000 sintetizando ideas que llevaban décadas circulando: el principio abierto-cerrado venía de Meyer, la sustitución venía del trabajo de Liskov sobre tipos abstractos, la inversión de dependencias venía del movimiento de componentes. El conjunto responde a una pregunta concreta: ¿por qué los sistemas OO se vuelven rígidos, frágiles e inmóviles con el tiempo? Los cinco principios son diagnóstico y receta para que los cambios queden contenidos en lugar de propagarse.
## Cómo piensa una skill inspirada en esto
- Antes de agregar un método a una clase, me pregunto si ese método introduce una nueva razón para que la clase cambie.
- Prefiero agregar una nueva clase o estrategia antes que meter otro `if` a un switch existente.
- Desconfío de jerarquías donde la subclase tiene que lanzar `NotImplementedError` o excepciones en métodos del padre.
- Rompo interfaces gordas en interfaces pequeñas cuando un cliente solo usa tres de diez métodos.
- Inyecto dependencias en el constructor; evito construir colaboradores concretos adentro de la lógica.
- Uso los olores de código —clases de 500 líneas, switches por tipo, excepciones en overrides— como alertas de violación.
## Cómo actúa
- Cuando una clase acumula validación, persistencia y notificación, propone separarla en tres con nombres claros.
- Si un `PriceCalculator` tiene un switch por tipo de cliente, refactoriza a estrategia antes de agregar un caso nuevo.
- Rechaza herencias donde el hijo debilita precondiciones o fortalece poscondiciones respecto al padre.
- Cuando un módulo de alto nivel importa una implementación concreta, propone una interfaz en medio e inyección por constructor.
- Al diseñar una interfaz nueva, lista los métodos y quita los que no todos los implementadores necesitarán.
- Pregunta por el contexto antes de aplicar SOLID a scripts, notebooks o prototipos — no todo código debe ser extensible.
## Señales de aplicar esta skill
- Diseño de módulos de dominio en sistemas de mediano a largo plazo.
- Refactor de clases que superaron varios cientos de líneas o acumulan responsabilidades.
- Integración de proveedores externos (pagos, email, storage) donde necesitas poder cambiarlos.
- Code review de jerarquías de herencia o interfaces públicas que otros consumirán.
No aplicar literalmente en scripts de una sola ejecución, prototipos de investigación, ni funciones puras pequeñas donde introducir abstracciones cuesta más que el beneficio. SOLID es para código que va a vivir y cambiar; no para código que nace para morir.
## Referencias
- *Agile Software Development, Principles, Patterns, and Practices*, Robert C. Martin
- *Data Abstraction and Hierarchy*, Barbara Liskov (1987)
- *Object-Oriented Software Construction*, Bertrand Meyer — origen del Open/Closed
- Wiki interna: SOLID
