Decomposing Large Classes into Single Responsibility Modules

In this lesson, you will learn how to identify "God Objects" in your Unity project and decompose them into focused, single-responsibility modules to improve long-term maintainability.

The Problem: The "God Object"

As your game grows, it’s common to end up with a PlayerController.cs that handles input, movement, health, inventory, and audio playback all in one file. This creates a "God Object"—a script that knows too much and changes for too many reasons. When a single class has multiple responsibilities, changing the health logic risks breaking your movement code.

The Solution: Decomposition

To follow the Single Responsibility Principle (SRP), we extract those independent behaviors into their own classes. Instead of PlayerController doing everything, it becomes a coordinator that delegates tasks to specialized modules.

For example, move your health logic into a separate HealthHandler class:

// Before: PlayerController.cs handled everything
// After: Dedicated logic component
public class HealthHandler : MonoBehaviour
{
    public float currentHealth;
    public void TakeDamage(float amount) 
    {
        currentHealth -= amount;
        // Handle death logic here
    }
}

Now, your PlayerController simply holds a reference to this module:

public class PlayerController : MonoBehaviour
{
    [SerializeField] private HealthHandler healthModule;
    [SerializeField] private MovementHandler moveModule;

    void Update()
    {
        // PlayerController focuses only on orchestration
        if (Input.GetKeyDown(KeyCode.Space)) moveModule.Jump();
    }
}

Why This Matters

By breaking the monolith:

1. Reduced Cognitive Load: You only look at the code relevant to the task at hand.
2. Simplified Testing: You can now write unit tests for your HealthHandler without needing to instantiate the entire player movement system.
3. Better Reusability: If you create an NPC, you can attach the existing HealthHandler to it, rather than copying and pasting from a massive, bloated PlayerController.

Decomposition isn't about creating "more files"; it's about creating "smaller, swappable parts" that make your game architecture resilient to change.

Key Takeaway: A class should have one, and only one, reason to change; if your script manages more than one distinct system, it is time to decompose it into focused, modular components.