Conviene haber comprendido Git y control de versiones para Unity.
CONTENIDO ORIGINAL
Avanza en orden. Cada lección está redactada para Palta es Cool, utiliza ejemplos propios y termina con una actividad cuya respuesta puedes desplegar.
ANTES DE EMPEZAR
Ubícate antes de avanzar
Al terminar deberías poder relacionar SRP y OCP con LSP e ISP y resolver un caso nuevo.
Reserva entre 75 y 120 minutos o divide el laboratorio en dos sesiones.
04 / PREPARA EL LABORATORIO
Instala Unity Hub, una versión LTS compatible y un IDE con integración para C#. Conserva un proyecto de laboratorio separado.
Abrir la guía de herramientas →Diagnóstico rápido: ¿cómo se relacionan SRP y OCP y LSP e ISP? ＋
No necesitas acertar todavía. Escribe una hipótesis de dos líneas y compárala con tu respuesta al finalizar; si puedes corregirla y justificar el cambio, hubo aprendizaje.
Aprende el tema paso a paso
Usarás SOLID como una lente para localizar cambios costosos, no como una obligación de crear muchas clases e interfaces.
Al terminar podrás
- SRP localiza razones de cambio y OCP contiene variantes
- LSP e ISP evitan sustituciones falsas y contratos inflados
- DIP hace que la regla dependa de contratos, no de detalles
01
Responsabilidad y extensión
SRP localiza razones de cambio y OCP contiene variantes
SRP pregunta por qué podría cambiar una unidad. OCP busca agregar comportamiento sin editar una cadena creciente de condiciones. En Unity, separar entrada, movimiento, salud y UI suele producir componentes enfocados.
Una responsabilidad se define por razón de cambio.
Extrae variantes solo cuando realmente cambian.
Refactoriza conservando comportamiento mediante pruebas.
¿Tener un solo método por clase garantiza SRP?
Mostrar respuesta ＋
No. Una clase puede tener un método que mezcle varias razones de cambio. SRP trata de responsabilidad y dependencias, no de contar líneas o métodos.
02
Respetar contratos
LSP e ISP evitan sustituciones falsas y contratos inflados
LSP exige que un subtipo cumpla las expectativas de su base. ISP divide interfaces para que cada consumidor dependa solo de capacidades que utiliza. Métodos vacíos o NotImplementedException suelen señalar un contrato incorrecto.
No fortalezcas precondiciones en un subtipo.
No obligues a implementar capacidades sin sentido.
Prueba el contrato con todas sus implementaciones.
¿Qué principio se viola si una torreta implementa Mover y lanza NotImplementedException?
Mostrar respuesta ＋
Principalmente ISP, porque el contrato exige una capacidad innecesaria; también puede romper LSP si se usa como un subtipo que prometía poder moverse.
03
Invertir dependencias
DIP hace que la regla dependa de contratos, no de detalles
La lógica de alto nivel recibe abstracciones para entrada, guardado o tiempo. El punto de composición conecta implementaciones de Unity. Esto permite sustituir dispositivos y probar sin cargar una escena completa.
La dependencia debe ser visible.
La abstracción pertenece a la necesidad del consumidor.
No introduzcas una interfaz si existe una sola colaboración estable y trivial.
¿DIP significa que toda clase debe tener una interfaz?
Mostrar respuesta ＋
No. Conviene abstraer límites variables o costosos. Agregar interfaces sin presión de cambio aumenta nombres y navegación sin beneficio.
Tu recorrido en tres ideas
- SRP localiza razones de cambio y OCP contiene variantes
- LSP e ISP evitan sustituciones falsas y contratos inflados
- DIP hace que la regla dependa de contratos, no de detalles
Desarma un PlayerController monolítico
Convierte razones de cambio, sustitución, contratos y dependencias en un refactor comprobable.
CASO
Un único componente lee entrada, mueve, recibe daño, actualiza UI, reproduce audio y guarda la partida.
Procedimiento
- Escribe una prueba o recorrido manual que capture el comportamiento actual.
- Extrae una responsabilidad por vez y vuelve a comprobar.
- Introduce contratos solo en límites que deban cambiar o probarse.
Evidencia mínima
- Mapa de razones de cambio.
- Prueba equivalente tras cada refactor.
- Nueva variante agregada sin editar el núcleo estable.
Mostrar razonamiento modelo ＋
Entrada entrega intención; Movimiento actúa; Salud conserva invariantes; Presentación observa; Guardado implementa un contrato. SOLID se justifica por cambios locales y pruebas más simples, no por aumentar archivos.
Para ir más lejos¿Qué extracción empeoraría la comprensión y deberías revertir?
CIERRE DE LA SECCIÓN
Comprueba que puedes usarlo
Antes de continuar, revisa estos tropiezos frecuentes y resuelve un caso sin copiar los ejemplos.
Aplicar SOLID contando clases o creando una interfaz para todo.
Refactorizar varias responsabilidades a la vez sin una prueba que conserve comportamiento.
Ahora hazlo sin guía
Toma un controlador que maneja entrada, movimiento, salud, UI y guardado; refactorízalo en pasos y justifica cada principio realmente aplicado.
Mostrar pauta de corrección ＋
Una respuesta sólida:
- Cada cambio responde a una presión y deja evidencia de comportamiento equivalente.
- Los contratos son pequeños y sustituibles.
- Las reglas de alto nivel no crean directamente detalles de entrada o persistencia.