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

Detectar el script dios

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.

Una clase = una responsabilidad principal.
Menos acoplamiento entre sistemas.
Mayor velocidad para depurar y evolucionar.

Separar Input, Movimiento y Audio

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.

Ejemplo básico de división por responsabilidad

using UnityEngine;

public class PlayerInput : MonoBehaviour
{
    public float Horizontal { get; private set; }

    void Update()
    {
        Horizontal = Input.GetAxisRaw("Horizontal");
    }
}

public class PlayerMovement : MonoBehaviour
{
    public Rigidbody rb;
    public PlayerInput input;
    public float speed = 6f;

    void FixedUpdate()
    {
        rb.velocity = new Vector3(input.Horizontal * speed, rb.velocity.y, 0f);
    }
}

public class PlayerAudio : MonoBehaviour
{
    public AudioSource source;
    public AudioClip jumpClip;

    public void PlayJump()
    {
        source.PlayOneShot(jumpClip);
    }
}

Refactor seguro en proyectos vivos

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.

1 Detectar el script dios 2 Separar Input, Movimiento y Audio 3 Refactor seguro en proyectos vivos

🧪 Aprende probando

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

⌄

🏁 Retos

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

⌄

🧰 Recursos

Enlaces útiles

Single-responsibility principle (SRP) C# object-oriented programming fundamentals Architectural principles (Microsoft) Unity Manual: MonoBehaviour Game Programming Patterns

Test

Comprueba tus conocimientos con un test sobre Unity.

Test de Unity

Recursos del curso 20

📘 Glosario 🎧 Audios 📄 PDFs 🖼️ Infografías 🎬 Vídeos 🔗 Enlaces 🧠 Flashcards

‹

Lección 14

UI en Unity: Canvas, Event System y texto dinámico

Lección 16

Patrones en Unity: Singleton y State Machine

›