Programming tips #2
overriding vs overloading

OOP in general is not something you should try to get good at

@stimulate why?

Personally, I don't think this really helps.

@putnam
Well it obviously always depends on what your priorities are, but if performance is important to you, OOP will never get you where you could be.

OOP is a very human way of understanding information, but computer's don't like to work that way. Your computer does not like to haul data object per object into cache, just to change one tiny data component of that single object. For your computer there is no button, no chair, no textbox. It is all just an illusion it has to create.

So the better, more cache-friendly way is the "data-oriented-programming"-way (DOP, if you will). It suggests that you pack all data, that you do similar processing on, tightly together in memory. That way the CPU will be able to do the same process over and over on a continuous array of the same datatypes, and than it can proceed and basically swap it's toolset once to work on another pile of data.

Let's say you are making a game (this is where this paradigm is most useful because it yields so much performance gains) and you want to have a bunch of objects with a position, a model, with vertices, materials, textures... All the things an object can have.

Now the hardliner OOP way, and the human way of storing the information for these objects would be: This object is a chair, it is standing in that corner, it is made of wood and that's why it's brown and why light reflects off of it smoothly, etc

But if you have 100 chairs, some may be made of wood, others from plastic, one has this shape, one has that, you can make a base class "chair" and inherit "PlasticChair" from it, but every time you want to change something about a chair by saying plasticChair.setPosition(vec3);, you are hauling all this data from the base and inherited class into cache and make the CPU find those 3 floats you want to change. And now you have to do that 100 times 60 times a second...

The more performance friendly (but more abstract) way would be to have an array of positions, an array of materials, an array of meshes, textures and so on.
Then, every object of your program just contains indices into those array ("the chair uses the 3rd position, the 1st mesh and the 6th material") and now, if you want to update all objects positions, you just have to get the array of all positions and of all objects, and maybe an array of all bounding boxes, and at that point all your CPU has to work with is that what it really needs. Every chair is now just a point in space and an area around it and using this you can do the same process (like collision checking) on all objects and update the position data in the position array.

Now, I understand that not every application requires this much cache friendliness, but I think either way, it is good to understand how computers like to work with data and I think once you are used to the DOP way of thinking, it is even easier than OOP.

@stimulate
some languages are very ligh level(python, ruby,...) and they are created for having fun with programming not having good performance.
In some cases that performance is the most important problem, DOP is better...

Nice, thanks for the explanation bro, i'll explore DOP after I grasp the knowledge about OOP completely.

@aliafzal
Yes, every tool has its purpose :)
@putnam
Sure, I did not really consider that not every application is performance sensitive, I guess my first comment was not really correct ;) OOP still owns the market and especially in a higher level it is good to know OOP