I was reading an interesting article today about a design methodology that I’ve been practicing since 1982, “Data Oriented Design”, or DOD for short. Since I have been using this (although, in typical fashion, without knowing it had an actual name) for quite a while the article was mainly interesting in the comments that many programmers had.
There were two serious misconceptions I saw expressed multiple times:
- DOD can not co-exist with OOP
- OOP == classes
Concerning item 1, I want like to point out two fundamental flaws:
- DOD -> Design && OOP -> Programming; two different but related parts of the solution
- There is no reason an “Object” can not be “Data Oriented”
Basically, using principles of DOD during your design phase for your data needs followed by using OOP principles during your design phase for your code needs should give you the best of both worlds. DOD should, in general, help your OOP goals.
Now, that said, there are going to be times when the two conflict. You may have cases where the best way to layout data does not meet with the best way to design your objects. In most of these cases it should be a simple matter of deciding which is most important, and which can be sacrificed.
I’d summarize the use of DOD + OOP as “Think about how the system will use your data, and design your objects so that their data is optimized for highest performance”.
Concerning item 2, I see a lot of C++ programmers making this mistake:
- An Object is not a class! (but a class should be an object!)
For instance, here is part of a comment from the above referenced article on DOD:
This is actually the same as OOP, except the function call is on the other side:
output = myfunc(input);
vs.
output = input.myfunc();
This statement is fundamentally incorrect, as OOP does not determine the syntax of objects to any degree or in any manner! Object Oriented Programming is a methodology, a design principle, programming paradigm, a concept, a practice, etc. It is not a language!
In other words, in the above reply, both function calls may or may not be conforming to OOP principles. Just because you have a class doesn’t mean you implemented OOP, and just because you don’t have a class doesn’t mean the code is not implemented with OOP.
Think of it this way; you can take any C++ code and translate it into C code (and, in fact, for many years C++ was actually implemented as just a pre-processor that output C code that the C compiler then compiled). Further, you can take the C code and create byte code from it (ie, LLVM for instance), or assembler or machine code. So, to say that you can not perform OOP in C, or assembler is quite silly. Same can be said for any other language as well.
Now, it is true that performing OOP in some languages may not be as pretty, or easy, etc. as it is in C++ in certain regards, but the fact is that it is possible. In fact, there are a lot of programmers who can legitimately argue that other languages, such as D, Objective-C or Ruby, are better at implementing OOP than C++.
-lane
I have been practicing OOP since the mid-80’s, and I didn’t start programming in C until 1990, before that all I used was assembler. If you look at any of the early id code (like Keen), you would find it’s very much DOD and a bit OOP, but in a very C manner (in some cases quite horrible to read).
Roathe.com 