Code Patterns

// WHY ECS OVER OOP?

// PROBLEM 1: Deep Inheritance Hierarchies
// OOP approach:
//   Entity
//     |-- LivingEntity
//           |-- Creature
//                 |-- Monster
//                       |-- ZombieBase
//                             |-- FastZombie
// Adding a "flying" ability requires modifying the hierarchy!

// PROBLEM 2: Diamond Problem
// What if FastZombie needs to be both Flying AND Swimming?
// Multiple inheritance causes conflicts

// PROBLEM 3: Class Explosion
// enemy_types * abilities * states = thousands of classes
// 10 enemies * 5 abilities * 3 states = 150 classes!

// ECS SOLUTION:
// Entities are just IDs
// Components are pure data
// Systems contain logic

// FastZombie in ECS:
// Entity #1234 has components:
//   - PositionComponent
//   - HealthComponent
//   - AIComponent(type: aggressive)
//   - SpeedComponent(multiplier: 2.0)
//   - ZombieAppearanceComponent

// Adding flying? Just add a component:
store.addComponent(zombieRef, FlyingComponent.getComponentType(), new FlyingComponent());

// The MovementSystem checks for FlyingComponent and handles it
// No class changes needed!

// PERFORMANCE BENEFITS:
// - Components are stored contiguously in memory (cache-friendly)
// - Systems process batches of similar entities efficiently
// - Archetypes enable O(1) queries for entity types