Data Oriented Design (DOD) has become a bit more popular lately, especially after Mike Acton, who popularized the term in his 2014 CPP talk, joined Unity.

Misconception about DOD 🔗

I feel like there's an unfortunate misconception about DOD going on, though. People started to use this term as though it implies using structure of arrays (SOA) for everything or even more specifically, using Entity Component System (ECS).

I've heard a phrase "I have the game state structured in data oriented way", which, to me, doesn't really say anything. If you look up DOD on Wikipedia, first sentence says "In computing, data-oriented design is a program optimization approach motivated by efficient usage of the CPU cache, used in video game development."

I think this misses the point of that philosophy. DOD is not as much about this design pattern specifically or optimizing for CPU caches. It's about approach to solving the problem.

What's Data Oriented Design really? 🔗

I think this becomes clear if you contrast it with Object-Oriented programming:

• OO is about creating a model of the world in the program and then solving problems by querying and modifying the model

• DOD is about looking for what actually needs to happen in the real world, and then structuring your program around that

Saying your data is "structured in data oriented way" doesn't say anything, because it depends on what your data looks like and how is it processed. If you say this to mean "I use SOA", you just jump to conclusions, because structuring something in "Data Oriented Way" could very well mean using AOS or any other data structure that fits the problem better.

It's totally possible that once you understand your data, you'll pick something similar to SOA in the end, but that should be the result of your analysis, not something you pick just because DOD or some smart person said that.

Rules of thumb 🔗

One deeper point that DOD evangelists criticize is how programmers often blindly follow rules of thumb without trying to understand the actual problem at hand - often making the problem more complicated than it needs to be as a consequence.

Unfortunately, the trend I just described doesn't change that. People just replaced the rules but keep following them blindly. Instead of OOP dogmas, we now have DOD dogmas, which feels paradoxical when the whole approach is centered around not following dogmas but physical reality.

On the other hand, it's just human nature to create shortcuts like this. Maybe it's not that surprising in the end. I don't perceive this to be such a big issue as it is in Object-Oriented programming.

OO is especially prone to this dogmatism, because it intentionally solves the problem by not solving it directly, but by building some abstract model. This leads to explosion of decision problems about the model that have nothing to do with what the program does, but how is it structured. These are more subjective and difficult to decide, because there's no simple objective measurement you can do to verify them. That's an environment where rules of thumb thrive.

Discussions: r/programming, Hacker news