DOP: Entity Component System (ECS) Pattern
Decouple game and domain architecture into Entities (IDs), Components (raw data), and Systems (pure logic).
Intent & Objective
Replace deeply nested, brittle class inheritance trees with pure composition of lightweight raw data components, processed by standalone systems.
"An entity is a simple peg; you snap on Position and Health bricks; a MovementSystem sweeps through and updates them without inheritance."
The Problem
The Deadly Diamond of Death in OOP inheritance: `FlyingMonster` inherits from `Flyer` and `Monster`, but `UnderwaterMonster` inherits from `Swimmer` and `Monster`. Soon you need a `FlyingUnderwaterMonsterBoss`, causing multiple inheritance nightmares.
The Solution
Entities are plain integers (IDs). Components are pure data structs without methods. Systems are stateless functions that query matching components and process them in bulk.
Key Participants & Architectural Roles
Code Samples (Traditional OOP vs Functional Programming)
Available in C++, Python, and JavaParadigm Contrast: Traditional OOP vs Functional / Data-Oriented
In OOP, an Entity is an object instance containing fields, virtual methods, and inheritance (`Monster extends Actor extends GameObject`). In ECS, an Entity is merely an integer ID, and all data and behavior are separated into flat tables of components and pure processing loops.
Advantages
- โ Zero inheritance trees; infinite flexibility to assemble any combination of behaviors
- โ Optimal memory layout and sequential processing
- โ Adding new behaviors is as simple as adding a new standalone system
Trade-offs
- โ Different paradigm from traditional OOP; requires rethinking entity relationships
When to Apply
- โ Game engines, simulation software, UI scene graphs, and complex dynamic systems
When to Avoid
- ! Simple applications with straightforward 1-to-1 database mapping