Which are the cons of using only non-member functions and POD?

Question

I'm creating my own game engine. I've read these articles and this question about DOD and it was written to not use member functions and classes. I also heard some criticism to this idea.

I can write it using member functions or non-member functions it would be similar. So what are the benefits/cons of that approach or when the project grows, does any of these approaches give clearer and better manageable code?

With POD & non-member functions I don't have to make struct members public I can still use object id outside of engine like OpenGL does with all it's stuff, so It's not about encapsulation.

POD - plain old data

DOD - data oriented design

Answer 1

I can write it using member functions or non-member functions it would be similar.

That's not the way to approach DOD. That's just the C syntax of object-oriented code. DOD means thinking about data before writing your code. OOP is often (but not always) the other way around.

Example: You're going to have 10000 visible, colliding particle objects in your game.

OOP: I'll start by making a Particle class. Each particle will have a "collide" function. Just so it integrates in the world, each particle will be an Entity too. The Collide function will be virtual because Entity has an abstract virtual Collide function. The Render function will be similarly designed.

DOD: Since we've got a lot of particles, it would make sense to store them closely together to minimize the time it takes to process them. There will be a collision processing function that handles all particles at once and can be optimized in any way, if necessary. To further optimize memory access, particle data will be separated into rendering, physics and common data arrays, depending on the actual data that is used. If particle count is going to be increased, these things will be considered: reducing size of color data, making some of the variable equal or at least non-integrated (curves/equations) for all particles (allowing to remove them from data).

Obviously DOD takes a lot more time and thinking. How much it's worth depends on the project. These days, when everything is calculated in one library or another, it might not matter much. But if you want to make something truly impressive, it's basically DOD-way or the highway.

Answer 2

Following an object-oriented design is preferred for most larger projects. Most games are about interactions between different objects in a game world, so I consider OOP to be especially suitable for game development.

When you design classes, you should generally declare all their variables private and manipulate them through public getter and setter methods (or getter and setter member functions, when you prefer that term).

Why?

Imagine you have some game object with a public variable. Imagine that you change and access it in a bazillion places all over your code.

Now imagine that one day you realize, that whenever this variable changes, something else needs to happen (show it on the GUI, report it to a server via network or whatever). Or when it changes, something else needs to be changed too (changing the size changes the mass, changing the temperature changes the color or similar interactions).

Now you would have to check your whole code for every case where this variable is changed and add code to do the above. And when you forget just one, you will have a bug.

But when the variable would be private, you could just add the above behavior to the setter method and you could be sure that the code will be executed whenever the variable is changed, no matter where and for what reason.

And that's just one simple reason why following object-oriented paradigms makes your project much more maintainable and reduces the likeliness of bugs. There are a lot of other design patterns in object-oriented programming which help you to structure your code in a much cleaner and flexible way. I could write a whole book about it here, but there already are enough of those. Like this very famous one:

http://www.amazon.com/Patterns-Elements-Reusable-Object-Oriented-Software/dp/0201633612