Arquitectura SOLID: responsabilidad única en Unity

Aplica SRP para dividir scripts gigantes en componentes claros, mantenibles y fáciles de testear dentro de tu juego.

📘 Teoría

Si una clase toca demasiados sistemas, ya tienes una señal de deuda técnica.

Un script dios acumula responsabilidades: lee input, mueve personaje, dispara audio, actualiza UI y controla checkpoints.

Cuando cambias una parte, rompes otra. Ese acoplamiento hace que corregir errores sea cada vez más caro.

El objetivo del refactor con SRP es aislar decisiones para que cada módulo sea simple de entender y mantener.

Divide por comportamiento funcional, no por conveniencia temporal.

`PlayerInput` interpreta controles y publica intención (moverse, saltar, atacar).

`PlayerMovement` transforma esa intención en velocidad, colisiones y desplazamiento físico.

`PlayerAudio` escucha eventos y reproduce sonidos sin mezclar lógica de física o estado del jugador.

Refactoriza en pasos cortos y verificables para no romper gameplay.

Empieza extrayendo una sola responsabilidad (por ejemplo audio) y valida que todo siga funcionando en escena real.

Usa commits pequeños por cada extracción de clase para poder revertir rápido si aparece regresión.

Define contratos simples entre componentes (propiedades públicas o eventos) para minimizar dependencias ocultas.

Ejemplo Ejemplo guiado Toma un controlador monolítico y separa primero la parte de audio en una clase dedicada.

⌄

Reto Reto práctico Propón una separación mínima en tres clases independientes para input, movimiento y audio.

⌄

Test

Comprueba tus conocimientos con un test sobre Unity.

Recursos del curso 20