An example of failing to follow DoD is the N+1 query problem: a programmer builds an abstraction that operates on individual DB rows, but "where there's one, there's more than one": you will inevitably be running that code in a loop so that you can process multiple rows. If instead the programmer had abstracted over groups of rows, then per-item query overheads suddenly become per-batch overheads.
People posted a wide variety of specific ideas under my other comment: https://news.ycombinator.com/item?id=49061421
I completely disagree with this characterization. OOP teaches you a synthetic set of concepts (go4) and then asks you to solve problems in terms of that.
And the reason why the canonical bird as a subclass of animal doesn’t work, is it’s extremely difficult to divide the world into strict categories (are you Aristotle). So the solution is to organize virtually rather than around natural traits.
The most natural way to solve a programming problem is a big list of instructions with if/else and goto. It’s very learnable, even for young children.
> And the reason why the canonical bird as a subclass of animal doesn’t work, is it’s extremely difficult to divide the world into strict categories (are you Aristotle)
What behavior are you going to out in vehicle? Here are a few potential subclasses you’ll need to consider:
- hang glider
- wheelies
- train
- skis
- lawn mower
- windsurfing board
When you look at it from that angle, rather than as an optimization technique, it makes it clear there is actually an elegant programming model here.
Unfortunately game engine programmers tend to think databases are super uncool and not relevant. They could actually learn a lot.
"flecs" pulls in some concepts from the relational algebraic world in that it has some sense of joins, etc. but it's a bit ad hoc.
The ultimate "data oriented design" game engine could be a high speed, GPU/SIMD accelerated, in-memory Datalog engine. And then the game world expressed in Horn clauses and logic.
https://github.com/timbran-project/mica is some of my playing in this area.
Maybe hardware- and access-aware more generally.
One of Mike Acton's other talks has a "Is Data-Oriented Design even a thing?" section, which goes over what he means when he refers to DOD: