Object Oriented Programming has been the buzz word for quite a long time in computer programming. The concept has even leaked to higher level issues such as OO Design and OO Analysis.
Just like any other buzz word in the world of information technology, Object Oriented programming has received much more attention than what it deserves.
But what does it really do? We all know that eventually all code written in a programming language needs to be translated into machine code and once in machine code, it is all the same, no matter writing your code in VB or python, it will end up in a unified language of instructions which the target machine knows well.
Object Oriented Design/Programming, is a way of adding a few conceptual layers between the problem domain in our real world and the instructions which need to be run by the target machine, a way of making a smooth transition between the layers of abstraction, a way to help our mind understand the problem and find a proper solution for it. After all, Object Oriented Programming is something to help us human beings overcome our limitations and be able to make better computer programs. Some argue that Object Oriented Programming brings with it new functionality which was not possible to have before such as Inheritance and Polymorphism, however, simple C structs and function pointers are all that you need in a structure programming language such as C to simulate inheritance and polymorphism.
All of these added values toward writing easier code for the programmers come with costs, sometimes huge costs. In other words intellectual manageability which is probably the most important aspect of Object Oriented Design comes with major costs, the most significant side effect is always performance.
Real-time simulation software have usually performance high on their priority list and so Object Oriented Design in such programs, such as games, needs some second thoughts. Such applications usually see their world as groups of data rather than groups of objects which contain data and behavior, unlike the way we see our world.
An example for the above is the way the main loop for a physics simulation engine works, all it cares about is a few data related to the physical properties and for it, other properties of an object such as its visual properties, sound and game related meta data is of no use.
In these cases, when a part of an application needs to work on specific data, in order to best utilize the system cache and increase the performance, it would be best to provide the relevant data to the sub-system rather than pushing in a whole object containing lots of data, just because handling the code in an object oriented manner is easier for us programmers. Multi-Processing can be managed easier once related data is batched together.
Enter Data Oriented Design. A rather harder way to look at the problem domain and to model which is by far easier and more efficient to process by the machine.
A very good article regarding Data Oriented Design can be found here:
Data-Oriented Design (Or Why You Might Be Shooting Yourself in The Foot With OOP)
And another very inspiring article is from Sony Research:
Pitfalls of Object Oriented Programming
Also a very nice presentation by Mike Acton:
Three Big lies: Typical design failures in game programming
Subscribe to:
Post Comments (Atom)
4 comments:
Why did you post those links?! Don't you know that I have to kneel and prostrate myself upon seeing any link to Acton's presentations?!?! You add the other two and I was on the ground for quite some time.
I'm joking of course. Great post and great articles/presentations.
personally I don't think dissing OO design completely is a good idea.
as the people in those articles said, it's just about the way u think about the application and designing ur code around data not the other way around. that doesn't mean u can't write in object-oriented language for data-oriented design, OO language just looks nicer and more maintainable, and can be easily used to write Data-oriented code.
I think any good programmer should know where to design for data, and where to design for the sake of good and extensible code. as all good programmers did before. it's just nothing really new !
the author just brings up the pros of data oriented design for concurrent and cache friendly code, which the performance critical areas of the engine needs the most
I totally agree that OOP received more attention than it deserved it, in the academic areas, and also I agree that we need to choose our way based on our priority ordered requirements list.
In some applications such as games that you focused in this article we cannot scarify performance by going for any method which gives us more maintainability or even productivity.
If we go back to general business information systems, I still agree that everything which is technically and theoretically possible in OOP is also possible in procedural or even linear programming. But I do not think they are possible practically! OOP actually gives us the ability to bring maintainability to our products in a more productive way in compare of the procedural software engineering.
And more important OOP makes it really really easier to divide huge projects' development process into phases/modules/parts and distribute them among very large teams of developers, to shorten the period of development.
Post a Comment