For the record, cache optimization is a subject of its own.
Data oriented design involves cache optimization, but I've already known cache optimization as a subject of its own for a long time and DOD is really a different issue. To me, one of the most important aspects about data oriented design is the myth of class-oriented extensibility e.g. write an abstract "Window" class, provide virtual methods such as SetTitle(), GetTitle(). Anyone with experience should know how it is a fault to expect the only thing to worry about after conceptually designing an abstract class (in a "straightforward" way, at least) is things like writing platform-specific implementations and so on.
Ever since I heard
"I slowly start to understand what they mean with data oriented design, you have to be careful where you place your data, and how you access it."
I knew this was heading a bad direction. -_-
Then I heard these two statements:
"Premature optimization is a curse on development. I've often been guilty of agonizing over bits and nybbles far to early in the dev cycle, trying to align datatypes on boundaries before the logic is in place."
"The best plan is one that can be easily modified to adapt to unforeseen circumstances. A plan that cannot be modified WILL be thrown away -- either before the plan is put into place, or shortly thereafter, the moment something goes wrong (which it generally will)."
That just made me go nuts. Class-oriented extensibility sounds like a harmless idea. The truth is that it does more harm than good. Unless you're DOING IT WRONG (and most people are), it is a real pain in the grass to do things right. You in fact need to plan more than you do if you just focus on using procedures to work through data. In other words, with data-oriented programming, you're not ideologizing code with procedurally inaffective, merely code-oriented functions like GetTitle(). For data-oriented programmers, writing explicit procedures
to directly manipulate data is more important than providing a convoluted plethora of methods which virtually construct procedures. Do you really want procedures to become more implicit? Writing a for() loop from the top-down is very easy after just a little experience. Trying to break down functionality from a flat loop into a deep stack of operation (lots of method calls) is a stupid idea.
For example, let's consider to conceptually have two different 'Window' types. One type of window can be resized and it requires the UI nested within (if any) to adapt to its new form. Another window cannot be resized.
The data in common can be put in a common place and targeted by a single routine. The data which is different can be seperated into multiple pools. If you have a list of indices which indicate which windows need to handle adjustments to their inner-contents, then you can pass through that list and perform the updates. That's straight forward. You don't need some bs like
for (uint resizableI = 0; resizableI != resizableQ; ++resizableI)
JUST HANDLE THE RESIZING OF ' resizable[resizableI]; ' AND MOVE ON WITH LIFE
This is also much more predictable and cache friendly. Despite how you'll have a few more loops, consider how each loop will have reduced, purposeful, data-oriented code, will be simple and straightforward, will perform predictably and only touch the data it needs (i.e. cache optimization stuff). Windows that don't need to bother with handling resizing actions don't need to suffer for trying to share all their data in the same pool of windows which do (and polymorphism is just a terrible way of emulating this). Also, most importantly, you don't need to worry at all about how the data will mesh together. This makes extensibility trivial. There's really no need for abstraction or generic programming. No need for polymorphism, no need for little booleans or flags etc.
These are the best articles in my opinion:http://molecularmusings.wordpress.com/2 ... ical-data/http://molecularmusings.wordpress.com/2 ... sh-data-3/
Most articles on that blog are pretty great. Here I've only listed two parts -- the best and most important, though -- of the series this author is writing on DOD. The other parts aren't essential to DOD, in my opinion. Some of the design decisions he makes in further articles, to be modest, are not the best solutions you can wager with DOD.
My two favorite blogs are molecularmusings.wordpress.com and fgiesen.wordpress.com (ryg is awesome!)