01
Qué es y qué problema resuelve
La mantenibilidad empieza por poder comprender intención, efectos y límites. Nombres concretos y funciones con una responsabilidad coherente reducen el tiempo de revisión.
Una función corta todavía puede ser confusa si esconde una modificación o utiliza números sin significado.
02
Ejemplo paso a paso
Punto de partida Una función pura expresa el límite; no conoce HTTP ni base de datos. El máximo es didáctico y necesita una fuente de configuración en una aplicación real.
Antes de ejecutar
Ejemplo de consola .NET 10. Integra el fragmento en Program.cs o en sus tipos auxiliares según corresponda; no mezcles declaraciones de tipos antes de instrucciones de nivel superior. No requiere una API ni una base.
const int MaximoAsistentesPorReserva = 12;
static bool AforoPermitido(int asistentes, int maximo) =>
asistentes > 0 && asistentes <= maximo;
Console.WriteLine(AforoPermitido(13, MaximoAsistentesPorReserva));Cómo funciona
- Lee el nombre de la función y qué significan sus parámetros.
- Identifica los límites permitidos y las condiciones que rechazan la entrada.
- Comprueba cero, el límite exacto y un valor superior.
Resultado esperado: False para 13; true para 1 y 12; false para 0.
03
Cuándo usarlo y qué debes evitar
Antes de optimizar, conserva un escenario reproducible y una medición. Revisa entradas inválidas, reintentos y permisos junto al camino feliz.
Una regla que aparece en tres endpoints debería tener un propietario único. Registra por qué eliges un patrón y en qué condición dejaría de ayudar; esa decisión evita que el siguiente cambio copie complejidad innecesaria.
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
Revisa una función de reserva y escribe una observación sobre intención, otra sobre efecto y otra sobre evidencia.
- 01Prepara el ejemplo con las dependencias indicadas en «Antes de ejecutar».
- 02Revisa una función de reserva y escribe una observación sobre intención, otra sobre efecto y otra sobre evidencia.
- 03Comprueba y registra el resultado: False para 13; true para 1 y 12; false para 0.
Ver solución orientativa
Comprueba nombre, estado modificado y prueba del borde. Evita comentarios que repitan exactamente una línea de código.
05
Comprueba lo aprendido
Responde antes de abrir la explicación. Esta comprobación es opcional y no guarda una puntuación.
01¿Agregar comentarios compensa un contrato ambiguo?
No. Primero corrige nombres, responsabilidades y garantías; documenta luego el razonamiento.
02¿Qué casos te permiten decidir si el límite de aforo está incluido?
Prueba 0, 1, 12 y 13 con capacidad 12. Solo 1 y 12 deben aceptarse: ese contraste documenta el límite inclusivo y rechaza el grupo vacío.
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.
- La regla admite 1 y 12 asistentes, y rechaza 0 y 13 para capacidad 12.
- La observación editorial explica intención, efecto y evidencia sin repetir el código.
Qué debes recordar
- Un nombre claro explica la intención.
- Los casos límite revelan errores que una entrada habitual no muestra.
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.