Unity and DevelopmentUnity and codeBeginner~6 min

Prefer events over Update ownership

Snapshot

~80 sec

Prefer events over Update ownership when a component only needs to react to a change. Polling in Update hides who caused the change; an event keeps the reaction on the signal that owns the fact.

You will learn

Contrast Update polling with an event subscription for the same invented readout.
Name who owns the score change versus who owns the label reaction.
Subscribe in OnEnable and unsubscribe in OnDisable so ownership stays temporary and explicit.

Target outcome

You can keep a small Unity reaction on the event that caused it instead of polling every frame.

01
Four ownership ideas
- Cause owner
  The component that changes the fact (score, health, pool state).
- Reaction owner
  The component that updates a view or side effect when the fact changes.
- Event
  A named signal the cause raises when the fact changes.
- Polling
  Reading the fact every frame in Update without a signal of change.

Update polling versus event reaction

Approach	Ownership	Work when idle	Debuggability
Read every frame in UpdateThe readout asks the board for score continuously.	The readout owns a constant question, not a reaction to a change.	Work happens even when the score never changed.	Harder to see which write caused a label flicker.
Subscribe to ScoreChangedThe board raises an event; the readout handles only that signal.	Cause and reaction stay on explicit components.	Idle frames do no score work.	You can breakpoint the event invoke and the handler.

03
Cause lane versus reaction lane
Read the sequence as two owners: the board writes the fact and raises the signal; the readout only reacts while subscribed.
SignalBoard (cause)
Mutate the fact
AddScore changes the board's own score field.
score += delta;
Raise the event
The board notifies subscribers without knowing who they are.
ScoreChanged?.Invoke(score);
ScoreReadout (reaction)
Subscribe
OnEnable attaches HandleScore to ScoreChanged.
board.ScoreChanged += HandleScore;
Update the view
HandleScore owns only the label reaction.
label.text = value.ToString();
Unsubscribe
OnDisable detaches so a disabled object stops reacting.
board.ScoreChanged -= HandleScore;
- SubscribeMutate the factwaits for
- Mutate the factRaise the eventthen
- Raise the eventUpdate the viewnotifies
- Update the viewUnsubscribeuntil disable
Read the sequence as two owners: the board writes the fact and raises the signal; the readout only reacts while subscribed.
Reading order
1. Subscribe
  OnEnable attaches HandleScore to ScoreChanged.
  board.ScoreChanged += HandleScore;
2. Mutate the fact
  AddScore changes the board's own score field.
  score += delta;
3. Raise the event
  The board notifies subscribers without knowing who they are.
  ScoreChanged?.Invoke(score);
4. Update the view
  HandleScore owns only the label reaction.
  label.text = value.ToString();
5. Unsubscribe
  OnDisable detaches so a disabled object stops reacting.
  board.ScoreChanged -= HandleScore;
Connection explanations
1. Subscribe → Mutate the fact (waits for)
  The reaction must be subscribed before a score change can reach the label.
2. Mutate the fact → Raise the event (then)
  The cause owns both the write and the signal that announces it.
3. Raise the event → Update the view (notifies)
  The event carries the new score so the readout never polls in Update.
4. Update the view → Unsubscribe (until disable)
  Unsubscribing ends ownership of the reaction for that object's lifetime.
Continue next
Object pooling in Unity with explicit state
Continue by keeping acquire, reset, and return as explicit ownership transitions.
04
Keep the reaction on the signal
Invented MonoBehaviours only. The board owns the score write; the readout owns the label reaction and the subscription lifetime.
Languagecsharp
```
public sealed class SignalBoard : MonoBehaviour
{
    public event System.Action<int> ScoreChanged;

    private int score;

    public void AddScore(int delta)
    {
        score += delta;
        ScoreChanged?.Invoke(score);
    }
}

public sealed class ScoreReadout : MonoBehaviour
{
    [SerializeField] private SignalBoard board;
    [SerializeField] private TMPro.TextMeshProUGUI label;

    private void OnEnable()
    {
        board.ScoreChanged += HandleScore;
    }

    private void OnDisable()
    {
        board.ScoreChanged -= HandleScore;
    }

    private void HandleScore(int value)
    {
        label.text = value.ToString();
    }
}
```
Code annotations
1. Lines 3-12
  Cause raises the event
  AddScore mutates score, then invokes ScoreChanged with the new value.
  Effect: Listeners learn about the change without polling.
2. Lines 19-27
  Subscribe for a temporary lifetime
  OnEnable attaches; OnDisable detaches so disabled objects stop reacting.
  Effect: Ownership of the reaction is scoped to the active lifetime.
3. Lines 29-32
  Reaction owns the view
  HandleScore updates only the label when the event fires.
  Effect: The readout never asks for score on idle frames.
Expected output
Observable ownership
When AddScore(5) runs, ScoreChanged fires once and the label becomes "5". No Update loop is required for that reaction.
Note
Update is still valid for continuous motion
Prefer events for discrete facts (score, unlock, pool release). Keep Update for continuous simulation that truly changes every frame. Mixing both is fine when each has a clear owner.
Choose the reaction style
A health bar should refresh only when damage or heal is applied. Should the bar poll health in Update, or subscribe to a HealthChanged event? Why?
Expected reasoning
Subscribe to HealthChanged (or equivalent). Damage and heal are discrete facts; polling every frame hides the cause and wastes idle work. The health owner raises the event; the bar owns the view reaction and unsubscribes when disabled.

Prefer events over Update ownership

You will learn

Target outcome

Visual walkthrough

Four ownership ideas

Cause owner

Reaction owner

Event

Polling

Update polling versus event reaction

Cause lane versus reaction lane

Mutate the fact

Raise the event

Subscribe

Update the view

Unsubscribe

Reading order

Connection explanations

Keep the reaction on the signal

Code annotations

Cause raises the event

Subscribe for a temporary lifetime

Reaction owns the view

Choose the reaction style

Play the subscription lifetime