🧩 Lesson 2.1: Thinking in Systems: Decoupling & Interfaces

The Spaghetti Problem

Imagine your Bullet script needs to damage whatever it hits. The quickest thing that works looks like this:

// ❌ The tempting, tightly-coupled version
void OnTriggerEnter(Collider other)
{
    Enemy enemy = other.GetComponent<Enemy>();
    if (enemy != null) enemy.TakeDamage(10);

    Barrel barrel = other.GetComponent<Barrel>();
    if (barrel != null) barrel.Explode();

    Player player = other.GetComponent<Player>();
    if (player != null) player.Hurt(10);
    // ...and a new branch every time you add a destructible thing 😱
}

It works today. But look at what it demands: the Bullet now knows about Enemy, Barrel, and Player. Add a breakable Crate tomorrow and you must come back and edit Bullet again. Every one of these GetComponent calls is a hard wire soldering two scripts together. That is tight coupling.

Coupled vs. Decoupled

Coupling is easiest to see. On the left below, the Bullet has a direct dependency arrow to every concrete type it can hit — a tangle that grows with the game. On the right, the Bullet depends on a single idea, IDamageable, and every destructible thing depends on that same idea instead. The tangle collapses into a hub.

Figure 1: On the left, every new destructible type adds a wire into Bullet. On the right, Bullet talks to one contract and never changes again.

Notice the payoff on the right: Bullet has one outgoing dependency, and adding Crate never touches Bullet at all. The new type just signs the same contract. That contract is what a C# interface gives you.

Interfaces: A Contract

A class says "here is what I am and how I do it." An interface says only "here is what I can do" — a list of methods and properties with no bodies. Any class that implements the interface promises to provide those members. The caller relies on the promise and stays blind to the details.

Think of it like a wall socket. Your lamp doesn't care what power plant is behind the wall — coal, solar, nuclear. It only relies on the contract of the socket: the right shape, the right voltage. Swap the power source and the lamp keeps working. An interface is that socket for your code.

💡 Interface vs. inheritance. You already know base classes. A class can only inherit from one base, but it can implement many interfaces. A Barrel can be both IDamageable and IInteractable at once. Interfaces describe capabilities that cut across your class hierarchy, which is exactly what gameplay needs.

Writing IDamageable

Here is the contract. It lives in its own file and, crucially, does not derive from MonoBehaviour — an interface is a plain C# type:

// IDamageable.cs
public interface IDamageable
{
    int CurrentHealth { get; }
    void TakeDamage(int amount);
}

Now any component that can be hurt signs the contract by listing it after MonoBehaviour and providing the members:

// Enemy.cs
using UnityEngine;

public class Enemy : MonoBehaviour, IDamageable
{
    [SerializeField] int maxHealth = 30;
    int health;

    public int CurrentHealth => health;      // satisfies the contract

    void Awake() => health = maxHealth;

    public void TakeDamage(int amount)        // satisfies the contract
    {
        health -= amount;
        if (health <= 0) Destroy(gameObject);
    }
}

// ExplosiveBarrel.cs
using UnityEngine;

public class ExplosiveBarrel : MonoBehaviour, IDamageable
{
    int health = 1;
    public int CurrentHealth => health;

    public void TakeDamage(int amount)
    {
        // any damage sets off the barrel
        Instantiate(explosionVfx, transform.position, Quaternion.identity);
        Destroy(gameObject);
    }

    [SerializeField] GameObject explosionVfx;
}

Two completely different behaviors — one loses health, one explodes instantly — but both honor the same promise: "call TakeDamage(amount) and I'll handle the rest."

Programming to an Interface

Now rewrite the bullet. Watch how the three branches collapse into one, and how Bullet stops mentioning Enemy, Barrel, or Player entirely:

// Bullet.cs — knows about ONE thing: the contract
using UnityEngine;

public class Bullet : MonoBehaviour
{
    [SerializeField] int damage = 10;

    void OnTriggerEnter(Collider other)
    {
        // GetComponent works on interfaces too
        if (other.TryGetComponent<IDamageable>(out var target))
        {
            target.TakeDamage(damage);
        }
        Destroy(gameObject);
    }
}

This is what "program to an interface, not an implementation" means. The bullet asks "are you damageable?" instead of "are you an Enemy? a Barrel? a Player?" Add a Crate : MonoBehaviour, IDamageable next week and the bullet damages it correctly the moment you press Play — you never open Bullet.cs again.

IInteractable in Practice

The same pattern powers the "press E to use" systems you see in every game — doors, chests, levers, NPCs. One contract, many implementers:

// IInteractable.cs
public interface IInteractable
{
    string Prompt { get; }     // e.g. "Open", "Talk", "Pick up"
    void Interact(GameObject interactor);
}

// Door.cs
using UnityEngine;

public class Door : MonoBehaviour, IInteractable
{
    [SerializeField] Animator animator;
    bool open;

    public string Prompt => open ? "Close" : "Open";

    public void Interact(GameObject interactor)
    {
        open = !open;
        animator.SetBool("Open", open);
    }
}

The player's interaction script casts a short ray, and — exactly like the bullet — never names Door, Chest, or NPC:

// PlayerInteractor.cs (Input handling shown fully in Module 3)
void TryInteract()
{
    if (Physics.Raycast(transform.position, transform.forward,
                        out RaycastHit hit, 3f))
    {
        if (hit.collider.TryGetComponent<IInteractable>(out var target))
        {
            ShowPrompt(target.Prompt);        // "Open"
            target.Interact(gameObject);
        }
    }
}

💡 A class can wear many hats. Give the ExplosiveBarrel both IDamageable and IInteractable and it can be shot and picked up. The bullet sees the damage contract; the player's interactor sees the interaction contract. Neither knows about the other.

A Note on Coroutines

Decoupled systems often need to do something over time — a barrel that flashes red for half a second before exploding, a door that takes a moment to swing. You could juggle timers in Update, but Unity has a cleaner tool you'll lean on constantly: the coroutine.

using System.Collections;
using UnityEngine;

public class DelayedExplosion : MonoBehaviour, IDamageable
{
    public int CurrentHealth => 1;

    public void TakeDamage(int amount) => StartCoroutine(FuseThenBoom());

    IEnumerator FuseThenBoom()
    {
        // flash a warning, then wait half a second without freezing the game
        GetComponent<Renderer>().material.color = Color.red;
        yield return new WaitForSeconds(0.5f);
        Destroy(gameObject);
    }
}

Read yield return new WaitForSeconds(0.5f) as "pause here, let the rest of the game keep running, and resume this method half a second later." No timer variable, no Update bookkeeping. We will use coroutines for spawning, fades, and cooldowns throughout the course; for now just recognize the shape.

Hands-on Challenge

Summary

🚀 What's Next?

Interfaces decouple who calls whom. But there's an even looser way to connect systems: let one system announce that something happened and let anyone who cares listen — without the announcer knowing who's listening at all. In Lesson 2.2: Events & Delegates we build exactly that with C# event, Action, and UnityEvent.