My favorite part about programming is the opportunity to keep learning new things, and recently one of those things has been Data Oriented Design. Having taken a class in optimization last year, I have a new appreciation for cache coherency (the final project was to optimize a program written in assembly, 90% of the optimizations I achieved came from simply having better data layout), so DOD is something I'm interested in pursuing.
After having read some the commonly cited articles on it, as well as having watched Mike Acton's cppcon talk on the subject, I have a much better grasp on this topic, but I still have a few questions.
It seems that Data Oriented Design is commonly brought up as the antithesis to Object Oriented Design. To me, OOD has always been about encapsulation, and it seems having that here would only be an even greater advantage. To combine the two, couldn't you just shift your thinking from objects as the data, to being views of the data? That way you could reorganize your internal data structures around every day, and as long as your OOP interface remains stable the rest of your code will be perfectly happy.
In all of the examples I've seen, it seems that you're essentially building new data structures specifically for each function, based purely on what data that function needs and how it will be operating on it. If that's the case, couldn't you be losing a lot of performance just transforming the data from one function so that you can pass it into another?
A lot of Mike Acton's criticisms of other code bases involved how people like to think of each function working on a single piece of data at a time, even though that's often not the reality of the situation. His solution to that was to refactor functions into operating on an array of values, rather than a single value. However, why couldn't you simply run that function in a loop, rather than putting the loop into the function?
At the beginning of his cppcon video, he listed Insomniac's priorities when it comes to code. I really appreciated him doing that, because he seems to be conveying that nobody actually thinks that this model somehow makes code more "beautiful" than before; rather that it solves the real problems that game developers face when shipping AAA games, in the least hideous way possible. My original resistance (hah) to DOD stemmed from my assumption that people were saying this makes code prettier, and I still really don't think it does.
Which brings me to my final question: as a hobbyist, my priorities are rather different than his. While I value performance, as long as things are running quickly enough I really don't care. Given that, I'd say my main metric for code quality is flexibility and beauty, which (from what I've seen) DOD doesn't necessarily promote. Can anyone here give some advice on how/where the best ways/places to apply this model would be, while still maintaining clarity and sanity in the rest of the code base?