I've read lots of articles about Data Oriented Design (DOD) and I understand it but I can't design an Object Oriented Programming (OOP) system with DOD in mind, I think my OOP education is blocking me. How should I think to mix the two? The objective is to have a nice OOP interface while using DOD behind the scenes.

I saw this too but didn't help much: https://stackoverflow.com/questions/3872354/how-to-apply-dop-and-keep-a-nice-user-interface


closed as too broad by Seth Battin, Josh Aug 10 '15 at 17:00

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 3
    \$\begingroup\$ You need to post something much more specific (and game-related), this question is far too general. \$\endgroup\$ – DeadMG Feb 2 '11 at 20:53
  • \$\begingroup\$ You're right, but I haven't seen this being discussed in other fields besides game programming. \$\endgroup\$ – Pombal Feb 2 '11 at 21:02
  • 4
    \$\begingroup\$ @DeadMG: I've never seen the term data-oriented design used outside game development, except when referring to practices originating in game development. If you are thinking of data-driven design, that is not the same thing. \$\endgroup\$ – user744 Feb 2 '11 at 21:53

I would say that Noel Llopis's blog is probably the best instruction for a combination of object-oriented programming and data-oriented design. He is one of the originators of the DOD term, is a strong C++ programmer, and has written a good deal about his style and how he takes advantage of C++'s OO features.

I guess if I were to call out the key elements of combining them, according to Noel:

  • Use POD and non-member, non-friend functions as much as possible. Non-member, non-friend functions improve encapsulation and are a key part of data-orientation because they keep the data, data.
  • Avoid storing "temporary" state on your objects. Temporary state clogs up your data. If you need to cache something (e.g. for performance) then that belongs in a new class, with non-member non-friend functions linking the two types, not a is-a nor a has-a relationship.
  • Avoid objects that can be in state A or state B. Prefer switching between two objects, one of which is A, and one of which is B.
  • Avoid polymorphism, avoid virtual functions, avoid templates, avoid anything that makes your data have the syntactic appearance of sameness rather than actual sameness.

The other big name in DOD propaganda right now is Mike Acton of Insomniac, but reading what he's written I'd say he's not really pro-OO (or anti-OO, as long as it's still data-oriented).

  • \$\begingroup\$ Thank you for the answer but what you're saying is what I should do to use DOD, not how I could use OO with it. I've read Noel's blog, Mike Acton's rants ( :D ), DICE's publications among others and I understand how to use DOD, just not with OO mixed in. \$\endgroup\$ – Pombal Feb 2 '11 at 22:32
  • 2
    \$\begingroup\$ What do you think OO is? I would call most of Noel's code OO, for example - there are still classes and instances, there is still type-based dispatch, there may still be inheritance (C++0x's definition of POD was changed to allow this). One still models problems starting with data, rather than operations. \$\endgroup\$ – user744 Feb 2 '11 at 23:18
  • \$\begingroup\$ For example polymorphism is a significant part of OOP, as like as states of object are. The data orientated design should be to give game entities properties like animate able, interact able, move able, ... using inheritance. It all depends on a clever data manager which provides only needed entities to each component e.g. for physics or animation. \$\endgroup\$ – danijar Oct 18 '12 at 13:57
  • \$\begingroup\$ @sharethis: If I understand your objection, it's that subtype polymorphism is a key feature of OO. I agree a language claiming to be OO without support for it would be strange, but that doesn't mean it's a tool of first resort for the kind of problems one encounters programming games, even when the game is programmed in an OO style. I would also argue that DOD is really about avoiding particular kinds of polymorphism (nominal subtyping) but encouraging of others (in C++, ad hoc polymorphism with ADL, or structural polymorphism via guarantees about value representations). \$\endgroup\$ – user744 Oct 19 '12 at 12:51

Not the answer you're looking for? Browse other questions tagged or ask your own question.