01
Qué es y qué problema resuelve
SOLID ofrece cinco preguntas para evaluar diseño: qué cambia una clase, cómo extender una variación, qué promete un subtipo, qué capacidades necesita un consumidor y hacia qué dependencia apunta el caso de uso. No es una puntuación ni una obligación de crear una interfaz para cada tipo.
02
Ejemplo paso a paso
Punto de partida Contrato pequeño para ilustrar segregación e inversión. Su implementación exige una decisión de persistencia que no forma parte de esta declaración.
Antes de ejecutar
Requiere un host ASP.NET Core 10 preparado. builder y app corresponden a WebApplication.CreateBuilder y Build; las variables y tipos auxiliares deben definirse. Registra los servicios usados antes de Build. El ZIP de consola no contiene esta API.
public interface IConsultaSala
{
Task<bool> ExisteAsync(string salaId, CancellationToken ct);
}
// CrearReserva depende de IConsultaSala.
// El adaptador de datos implementa la consulta.
// El consumidor no conoce SQL ni configuración de conexión.Cómo funciona
- Identifica la necesidad del consumidor: consultar una sala.
- Declara un contrato pequeño que represente esa necesidad.
- Deja al adaptador la consulta concreta y al caso de uso la coordinación.
Resultado esperado: Puedes probar el caso de uso con una sala presente o ausente sin cambiar su dependencia.
03
Cuándo usarlo y qué debes evitar
En Reserva de espacios, el caso de uso cambia por coordinación del negocio y el adaptador por el motor de datos. IReservas separa esas razones.
Una consulta no debe depender de métodos de administración que nunca usa. El contrato de GuardarAsync debe describir qué queda confirmado; un mock que siempre devuelve éxito no verifica esa garantía.
Ampliación opcional · contexto y variantes del tema
Aplicar los cinco principios SOLID con criterio
S: responsabilidad única significa una razón coherente de cambio. Reserva cambia por reglas del negocio; un serializador cambia por el formato HTTP. O: abierto/cerrado propone extender comportamiento estable mediante puntos de variación útiles; agrega un segundo canal de aviso sin reescribir CancelarReserva. L: sustitución exige respetar precondiciones, resultados y efectos del contrato; un repositorio alternativo no puede devolver éxito antes de guardar si el contrato promete persistencia.
I: segregación de interfaces evita que una consulta de disponibilidad dependa de métodos para borrar reservas. D: inversión de dependencias hace que el caso de uso conozca un contrato IReservas y que el adaptador de almacenamiento lo implemente. Inyección de dependencias es el mecanismo que entrega el objeto; inversión es la dirección de la dependencia. Se puede inyectar una dependencia concreta y seguir teniendo un acoplamiento incorrecto.
Usa composición para sumar capacidades independientes. Una jerarquía Sala → SalaVirtual puede ser problemática si su contrato exige aforo físico o dirección postal. Una colección de atributos o políticas expresaría mejor diferencias reales. No introduzcas fábricas, interfaces genéricas y herencia para anticipar variantes que todavía no existen. Explica qué cambio previsto justifica cada frontera.
Punto de partida La aplicación pide dos capacidades. La implementación puede usar una base de datos; el dominio no importa ese detalle. GuardarAsync representa la confirmación del trabajo pendiente en el ámbito.
Antes de ejecutar
Contrato compilado en el laboratorio
public interface IReservas
{
Task<Reserva?> BuscarAsync(Guid id, CancellationToken ct);
Task GuardarAsync(CancellationToken ct);
}Resultado esperado: CancelarReserva se prueba con MemoriaReservas sin levantar HTTP.
04 · Práctica guiada · opcional
Practica lo aprendido
Separa una clase que recibe HTTP, consulta SQL y envía avisos en tres responsabilidades.
- 01Prepara el ejemplo con las dependencias indicadas en «Antes de ejecutar».
- 02Separa una clase que recibe HTTP, consulta SQL y envía avisos en tres responsabilidades.
- 03Comprueba y registra el resultado: Puedes probar el caso de uso con una sala presente o ausente sin cambiar su dependencia.
Ver solución orientativa
HTTP traduce el contrato; el caso de uso coordina; adaptadores consultan datos y entregan avisos. Explica una razón de cambio por componente.
05
Comprueba lo aprendido
Responde antes de abrir la explicación. Esta comprobación es opcional y no guarda una puntuación.
01¿DIP equivale a registrar AddScoped?
No. DIP describe la dirección de dependencias; DI entrega instancias y puede inyectar un diseño mal acoplado.
02¿Qué responsabilidades separarías antes de sustituir el almacenamiento?
Separa traducción HTTP, coordinación de la reserva, consulta de datos y entrega de avisos según sus razones de cambio. El contrato del caso de uso no debe exponer SQL ni respuestas HTTP.
Cómo demostrar el objetivo
Compara tu práctica con estos resultados. Si solo diseñaste una prueba, registra su resultado como esperado, no como observado.
- Asignas la traducción HTTP, la coordinación y el acceso a datos a responsabilidades explícitas.
- Justificas una razón de cambio por componente y evitas tipos de SQL en el contrato del caso de uso.
Qué debes recordar
- Una responsabilidad tiene una razón de cambio.
- Una abstracción debe servir a su consumidor.
Tu cuaderno · notas personales
Cuaderno local
Tus notas del contenido
Se guardan únicamente en este dispositivo. Puedes exportarlas cuando quieras.
Material de apoyo · descarga, glosario y referencias
Explicaciones, ejemplos y prácticas propios de Academia de Software. Los fragmentos de integración requieren las dependencias indicadas; el ZIP contiene el núcleo de consola. Las lecturas externas se consultan en su sitio original y conservan sus condiciones. Procedencia y condiciones de uso.