In object oriented design, there is a strong tendency to implement the set of responsibilities in the same place as the schema of the data. In C++ this is caused by declaring the internal representation and external interface in the same place. The pImpl idiom can mitigate some of the inherent problems in this approach, but in general, thinking about data as an object consistently deflects criticism that the programmer is keeping too much information available when it's not used.

For example, the this pointer points to all the members of an object, not just the ones necessary for the member function. Attempting to reduce the available items to only those necessary for the transform cuts data members from the object. This is normally impossible due to each object's member functions having disjoint sets of considerations. To make the this pointer only point to pertinent data and no more, we have to completely change how member functions of a class take their responsibilities and turn them into access patterns. This is a non-trivial change.

C++ classes inherently couple data members of a class to each other via their member functions and member functions are coupled to each other by the data they operate on. To reduce coupling, you have to invoke higher level lower performance features of the language.

In conclusion, keeping your data in collections of actually related data is better than keeping them in collections of related by owner. In many cases, game engines already separate out parts of entities into different pieces such as physics, rendering, gameplay, and audio entities. The optimal solution is somewhere between this and every member of every entity being accessed purely by foreign key.

http://www.1keydata.com/sql/sql-foreign-key.html

DATA-ORIENTED DESIGN The hardware will thank you.

Chinese translation provided by KouZhe / Martin Cole

Seperation of schema from responsibilities 01/12/2011:17:07:14