The Mental Model: From Scripts to Autonomous Entities
The Shift: Data Pipelines vs. Autonomous Agents
Most computational training begins with Procedural Programming. You treat a program as a pipeline: you define passive data structures, and you write global functions that process that data step-by-step.
Object-Oriented Programming (OOP) requires a fundamental shift in perception. You stop looking at the program as a sequence of transformations and start looking at it as a "System" populated by independent Entities (Objects). Instead of passing data into functions, you send messages to entities, asking them to update themselves.
| Architectural Trait | Procedural Thinking | Object-Oriented Thinking |
|---|---|---|
| State Management | Global or passed explicitly | Localized within the entity |
| Primary Unit | Pure Functions / Routines | Autonomous Objects |
| Coupling Risk | Functions tightly coupled to data shapes | High, if inheritance is abused |
| Best Used For | Mathematical transformations, data parsing | Simulations, UI components, complex systems |
The Failure of Procedural Scaling
In a small script, procedural code is highly efficient. But as a system's complexity scales—imagine a kinematic simulation with particles, fields, and constraints—procedural code often degrades. Global functions become bloated with if-else type-checking, and any change to a data structure breaks hundreds of independent functions.
{/* prettier-ignore */}
In the procedural example above, the updatePosition function is a bottleneck. It has to "reach in," analyze the type, and apply the correct physics.
The "Entity" Mental Model
To think in OOP, you must encapsulate the data and the physics into a single "Black Box". Every component in your system requires three things:
- Identity: A unique reference in memory.
- State: What the entity knows at a given
t(e.g., its coordinates, velocity). - Behavior: What the entity does (e.g., calculating its own next position).
{/* prettier-ignore */}
In this model, the overarching system does not calculate the math. It simply issues a command: update(dt). The entities know how to resolve their own physics.
The Four Pillars of Architecture
To engineer a professional system, your mental model must rest on four architectural pillars, which we will explore exhaustively:
- Encapsulation: Building walls around your state so external systems cannot introduce invalid mathematical or logical states.
- Abstraction: Providing a high-level interface (a steering wheel) while hiding the low-level mechanical implementation.
- Inheritance: Establishing hierarchical "is-a" relationships to share structural DNA.
- Polymorphism: Designing systems where different entities can be swapped seamlessly because they respond to the same commands.
What You Have Learned
- System vs. Script: OOP shifts your role from writing sequential scripts to architecting a system of actors.
- Decentralized Logic: Instead of global functions parsing passive data, logic is decentralized into the objects themselves.
- Scalability: The OOP model scales because adding a new entity type does not require rewriting the core system loop.
In the next lesson: Encapsulation — how to protect your entity's internal state from the rest of the application.