OOP. Not oops

Box-Object
Box Object

You're here for two possible reasons: looking for Object Oriented Programming or wasting your time (too much oops in your life).
Even we hope for the first but it's not your case, remain here to read and see if this proposal can catch you.

By watching a picture we generally see stuffs represented, and we call them with the same name used in all days life: but as just said, they're representation. The picture conveys an information we're able to understand, but it cannot brings you the exact object it shows.
But what is an object?

Good question and so difficult the answer is: primarily we rely on our sensory perceptions, then getting a major abstraction while we grow, until we arrive at a certain point where we confuse the object with its representation we have in our mind.

We don't indicate us as an exemplar of human being, but as man or woman; on the other side we'd surely define us as an exemplar of human being. And this a good starting point, the separation between a definition and its possible specification.
In previous programming proposal we encountered something similar, with a type's definition against a variable's declaration of it: while the first passage gives a name to some rules and features, the second one brings an exemplar of it into light, with its specific name.

The record type is perfect to understand the above talk, and what we're going to discuss here is a special construction that can be viewed like a super set of a record (of a structure in C++).

We already gave some tracks in previous articles about objects, especially talking about the TList used to manage dynamical arrays efficiently: we saw that a "variable" of a TList "type" has some properties not only the classical variables but functions and procedures too.
This step is fundamental because at a deeper look it reveals a change in the programming paradigm, and so a change in software designing and realization.

The passage brings us from the how to the who/what.

Procedural programming is based upon a functional approach, where the action and its flow are the main guides: in a very brutal way it can be assumed as a line that starts from a point and ends into another, where the line is a series of actions.
[Sorry for this image, surely incomplete, but not so far from the truth]
In some way, programming with objects is similar: we simply use the objects like boxes, more powerful than the normal variables. Just this!

But if you want to get inside the Object Oriented vision, you must move the focus to the object itself; or better to its more generic representation, called class.