Chapter 4
Responsibility Before Functionality
"Software becomes difficult to understand when systems are defined by what they can do instead of what they are responsible for."
Why This Chapter Exists
As software grows, new features inevitably appear.
Validation.
Networking.
Saving.
Animation.
Customization.
Debugging.
Optimization.
None of these features are problematic on their own.
The challenge begins when every new feature is added to the nearest existing system.
A validator begins loading assets.
A runtime object starts validating itself.
Gameplay becomes responsible for networking.
Managers begin managing other managers.
Over time, software stops growing through architecture.
It grows through accumulation.
This chapter introduces one of the most important principles of the Cube Framework.
Responsibilities come first.
Features come later.
The Difference Between Responsibility and Functionality
These two concepts are often confused.
Functionality describes what a system is capable of doing.
Responsibility describes why the system exists.
This distinction is fundamental.
A Runtime Builder may eventually support many different features.
Validation.
Dependency resolution.
Assembly.
Initialization.
Its responsibility, however, remains unchanged.
It transforms validated information into executable runtime representations.
Every feature should reinforce this responsibility.
Not replace it.
Responsibilities Define Boundaries
Responsibilities naturally create boundaries.
Whenever a subsystem receives a new feature, one question should always be asked first.
Does this feature strengthen the responsibility of this system—or does it belong somewhere else?
If the answer is unclear, the architecture should be reconsidered before the code is written.
Healthy boundaries rarely emerge accidentally.
They require deliberate decisions.
Features Change. Responsibilities Should Not.
Gameplay evolves continuously.
New mechanics appear.
Old mechanics disappear.
Networking requirements change.
Content expands.
Responsibilities should remain remarkably stable.
The purpose of a Runtime Builder today should still be recognizable years later.
Implementations evolve.
Responsibilities endure.
This stability allows entire subsystems to improve without forcing architectural redesign.
Cooperation Instead of Ownership
One common misconception is that a subsystem must own every process in which it participates.
The Cube Framework deliberately avoids this approach.
Subsystems cooperate.
Validation prepares information.
Assembly transforms it.
Networking synchronizes it.
Gameplay consumes it.
Each subsystem contributes one part of the process before passing responsibility onward.
No subsystem attempts to own the entire workflow.
This creates architecture that scales naturally as new systems are introduced.
Small Responsibilities Create Large Systems
At first glance, separating responsibilities appears to increase complexity.
There are more classes.
More subsystems.
More interactions.
Interestingly, the opposite usually happens.
Each subsystem becomes easier to understand.
Developers require less knowledge before making changes.
Responsibilities remain obvious.
Complexity moves away from individual systems and into the relationships between them.
Architecture becomes sophisticated.
Implementations remain simple.
Knowing When To Stop
Perhaps the greatest benefit of clear responsibilities is restraint.
Every subsystem eventually reaches a point where its work is complete.
The Runtime Builder assembles.
It does not simulate gameplay.
The Validator verifies.
It does not assemble runtime objects.
Networking synchronizes.
It does not determine gameplay rules.
Knowing when to stop is one of the defining characteristics of mature software architecture.
Design Note
Whenever introducing a new feature into an existing subsystem, avoid asking
"Can this class perform the work?"
Instead ask
"Should this responsibility belong here?"
The answer often determines the long-term health of the architecture far more than the implementation itself.
Framework Law IV
Responsibilities define architecture. Features merely inhabit it.
When responsibilities remain stable, architecture remains understandable—even as functionality continues to grow.
Revision History
Version 1.0
Initial publication.