Scope is not ownership

990. Lesson identity

Module

3.2 — Global and local state

Lesson

1 — Scope is not ownership

Academic type

Concept

Schema type

text

Order

1 in the module

Estimated time

30–45 minutes, including practice

991. Learning objective

After this lesson, you can identify a state's current access boundary, compare it with the systems that legitimately need access, and separately classify its authoritative writer, lifetime, and persistence.

992. Why this matters

A value can be accessible to an entire application even when only two systems need to read it. That mismatch is easy to miss when scope is described only as a list of intended readers.

Broad access may be convenient, but convenience does not prove that the state belongs at a global boundary. It also does not grant every system permission to write. When these decisions are merged, code can acquire competing writers, hidden dependencies, stale copies, and state that survives longer than the thing it describes.

The goal is not to make every value private. The goal is to make four decisions explicit: who can access the state now, who should need access, who may change it, and how long it should exist or survive.

993. Prior knowledge

You should be able to trace one action through creation, update, communication, and teardown from 3.1 L2 — Trace one action through the architecture. You should also recognize components, services, events, and runtime owners.

994. Core concept

Scope is the state's actual access boundary. Ownership is the authority to validate and commit changes. Required readership is a design requirement used to judge whether the current scope is appropriate.

Ask two different access questions:

1. Current access: Which systems can access this state under the present design?
2. Legitimate need: Which systems actually need to read or request changes to it?

A mismatch between those answers is evidence for review. For example, a globally accessible currency value may be needed only by the economy feature and its UI. Its current scope is application/global even though its legitimate reader set is small.

Use consistent scope labels:

• Component/object: accessible only through one object or one of its components.
• Feature: accessible within a bounded feature, such as inventory or combat.
• Scene or run: accessible to systems participating in the current scene or run.
• Session: accessible across scenes for the current play session.
• Application/global: accessible broadly throughout the application.

These labels describe access boundaries, not how important a value is and not who owns it.

Classify the remaining dimensions independently:

• Authority: Which system validates and commits a change?
• Lifetime: When is the value created and discarded?
• Persistence: Does the value survive a defined boundary, such as a scene change, the end of a run, or an application restart?

A value can therefore have application/global access, only two legitimate readers, one authoritative writer, a session lifetime, and no persistence. That combination may reveal an unnecessarily broad scope without changing the authority decision.

995. Decision model

For each state value, record six answers:

A useful communication pattern is:

Reader observes → requester asks → authoritative writer validates and commits → readers receive the result.

A requester does not become the owner merely because it initiated the action. Likewise, a system does not become a legitimate reader merely because a global reference makes access possible.

996. Concrete example: player stamina

Suppose stamina is stored in an application-wide service that any system can access.

• Current scope: Application/global, because any system with the service reference can access the value.
• Legitimate readers: The sprint controller and HUD need to read stamina. A rest interaction may need to request recovery.
• Desired scope: Player feature or player object, provided the required readers can observe or request changes through that boundary.
• Authority: The stamina system validates maximum stamina, consumption, and recovery, then commits changes.
• Lifetime: The current player instance or current run, according to the design.
• Persistence: None if stamina resets for a new run. It is persistent only if the design requires restoration when loading a saved game.

The global service does not prove that stamina needs global scope. The HUD's need to display stamina does not make the HUD an authoritative writer. The sprint controller's request to consume stamina does not authorize it to bypass stamina rules.

This example separates three facts that are often confused:

1. What can access the value now.
2. What legitimately needs access.
3. What may validate and commit a change.

997. Common mistakes

Mistake 1: Defining scope as intended readership

Saying “the HUD and combat system read health” identifies readers, but it does not identify scope. If health is stored in a global registry, its current scope is application/global even if only those two systems should read it.

Mistake 2: Treating global access as global ownership

A shared manager may let UI, input, and gameplay code assign the same value directly. Accessibility does not authorize those writes. Name one system that owns the validity rule and require other systems to read or request changes.

Mistake 3: Treating persistence as ownership

Saving a value does not make the save system the owner of its gameplay meaning. The gameplay owner defines valid state. The persistence layer records and restores it at an agreed boundary.

Mistake 4: Choosing a broad scope only for convenience

A global reference can reduce short-term wiring, but that is not evidence that unrelated systems should gain access. Compare the current boundary with legitimate readership and choose the narrowest boundary that still supports the required collaboration.

998. Guided practice

Classify each state value. Do not infer current scope from the listed readers: first use the stated storage or access mechanism to identify who can actually access it.

1. A door's open state is stored on the door component. Its animation and interaction prompt read it.
2. Player currency is stored in an application-wide registry. The economy service and shop UI need to read it; purchases must be validated by the economy service.
3. A graphics setting is available through the settings feature across scenes and must remain after restarting the application.
4. An enemy's “already reacted to this trigger” flag is stored on that enemy instance and is read only by its behavior component.

Use this table:

Use one of these labels for each current and desired boundary: component/object, feature, scene/run, session, application/global.

Then inspect the currency row:

• Identify the mismatch between current access and legitimate need.
• Decide whether the desired boundary should remain application/global or become narrower.
• Name the authoritative writer independently of that boundary.
• State the unsafe assumption that could allow the shop UI or another convenient caller to write currency directly.

999. Validation and evidence

Your classification is complete when every row includes:

• A current scope based on who can actually access the state under the stated design.
• A separate list of legitimate readers and requesters.
• A desired scope using a consistent boundary label.
• A reason for keeping or narrowing the current boundary.
• One authoritative writer that owns the validity rule.
• A lifetime tied to an object, feature, run, session, or application boundary.
• A persistence decision naming the boundary that is crossed or not crossed.

Check the work with these tests:

• If a value is globally accessible but only two systems need it, did you record application/global as the current scope rather than naming those two readers as the scope?
• If a UI reads a value, did you avoid granting it write authority without a validity rule?
• If a value is saved, did you keep gameplay authority separate from storage and restoration?

Defend each writer choice with: “This system is authoritative because it owns the rule that determines whether the change is valid.”

1000. Key takeaways

• Scope describes the actual access boundary.
• Required readership describes which systems legitimately need access.
• A mismatch between broad access and narrow need can reveal unsafe global convenience.
• Ownership identifies the system authorized to validate and commit changes.
• Readers and requesters do not gain write authority through access alone.
• Lifetime and persistence remain separate from scope and authority.

1001. Next lesson

Continue to 3.2 L2 — Build a state-ownership sheet / Crear una hoja de ownership de estado.

1002. Knowledge check