originally posted on sweng-gamedev

Perhaps this summary may aid yours and others thinking:

1) Never forget the CPU loads data from memory transforms it (in Acton-speak) and writes the modified data out
2) It doesn't transform just one input and produce one output - it processes streams of data whether or not you choose to see it that way
3) The natural unit of program composition is not a conceptional 'OO' object but functions that transform an input stream to an output stream (stream or list)
4) It sounds simple and obvious and it is - but decades of 'OO' teaching have obscured this fact in many peoples minds
5) Functional decomposition leads to extremely reusable code without the awkwardness OO constructs can introduce
6) By functional decomposition I mean your function only reads its input and writes its output and touches no hidden shared state inside
7) If you view the input and output parameters that are connecting your functions as asynchronous streams rather than instant value parameters I would suggest writing concurrent code becomes much easier
8) Such parameter streams can be implemented as message passing lockless queues (Forget STM) and functions can be invoked when they have parameters to process by kicking them to a pool of worker threads
9) Push your iterations on the parameter streams down to the lowest level function they can go and you get the 'Action: 'Where there is one there is many'
10) Notice how tuples of parameter stream data can be efficiently processed by SSE instructions etc
11) Investigate what this means in respect to languages such as Erlang, Haskell, C#, F#, C++, C and understand why in lots of ways staying closer to the C subset of C++ in OO constructs is a good thing (Templates on such functions are great tools also)
12) View your input parameters as immutable data structures
13) Optimise your immutable data structures by performing copies only when necessary and providing garbage collection for them and transmission support for distributed computing (Understand how this maps to functional language compiler optimisations) - and how this can collapse to simple double buffer schemes in cases etc
14) Notice how efficiently a component/aspect/state/whatever entity system can be implemented in tandem with this and how well this maps to relational database tables (and ignore object orientated databases from now on)
15) Organise data into tables of actual data and sets of different indices into that data - and think in terms of queries, adds/removes and updates
16) Just have structs of data with the only functions allowed being initialisers and those that can compute values from the data in an immutable fashion
17) Read up on dataflow/flow based programming and model your programs by data flow and transforms on the data rather than ANY CLASS HIERARCHY AT ALL
18) Put this into practice in your C++ projects by using only static functions of the form described utilising the grouping features of namespaces and then if a naturally easy to use object orientated hierarchy fits nicely on top of certain collections of functions then create OO objects that utilise your existing static functions. Notice how this probably fits lots of the advice of good OO programming.

I hope that helps!

Cheers,

Warrick Buchanan

DATA-ORIENTED DESIGN The hardware will thank you.

Chinese translation provided by KouZhe / Martin Cole

Warrick Buchanan's N step plan for data oriented thinking 15/11/2011:23:07:56