I'm trying to wrap my head around the distinction between Data Oriented Design (DOD) and Object-Oriented Programming (OOP). From what I gather, DOD feels a bit like OOP but without having methods tied to each "object". Instead of making objects handle their own functions, you write functions that work on the data directly. For example, in a game where I have a zombie, the OOP way would be to create a method called `TakeDamage(DamageAmount: int)` for the zombie object. On the other hand, in a DOD approach, I'd just create a function that modifies the zombie's health within an array that represents its data. Have I got the gist of DOD, or am I misunderstanding it? I'd love any clarification!
4 Answers
It's a common misconception that DOD and OOP can't mix. In fact, blending both can lead to some pretty robust solutions! Often, you end up writing functions for specific tasks rather than bundling everything into an object. Think of it as leveraging the best of both worlds.
DOD splits the focus on how data is stored and accessed in memory, and it doesn’t contradict OOP principles. It’s a mistake to think they lead to starkly different coding styles; you can craft structures that work hand-in-hand.
You’re on the right track with DOD! But it's crucial to note that OOP isn't one-size-fits-all. What you described is a simplified version that many learn in school, but in practice, many developers find DOD far more flexible. For instance, when you try to inherit properties like 'Vehicle' for both a Car and a Boat, it can get tricky: boats don’t have wheels! Refactoring becomes a pain when your hierarchy gets tangled. It's about finding what works for your project!
Right? Like, what do you with `getNumWheels()` for a Boat? Sometimes it can lead to unnecessary complexity.
Don’t forget that OOP introduces subsumption: if a zombie is a GameObject, it can stand in wherever a GameObject is required. While DOD can accommodate this principle, it doesn’t have to. It’s really up to your preferences on how to design your system.
Exactly! It’s all about writing code that fits your situation. Sometimes I just leave a comment saying I’d like to make it a method later but need it as a function now.