“We are all made of stars” sings Moby in one of his top-selling tracks, and how could I disagree with that?!

If there are about 7,000,000,000,000,000,000,000,000,000 atoms in a 70kg human body, and if we would consider atoms as objects, is everything an object, even us?

Thanks to the progress of abstraction, in OOP it is possible to take conceptually any real-life component and build a software representation of it.
For example, we can create a Dog object, a Car object, or  a Human object.

Each one of these objects has in its basic definition both data and behaviour, being data in the form of attributes’ values, and behaviour the actions it takes when receiving a particular request.

Having both data and behaviour is the key difference between object-oriented programming and the procedural approach. In well-designed object-oriented software, nothing outside the object can change directly the value of its attributes, and the only way to communicate with the object, or have it doing anything, is to send it a message.

We could at this point narrow down the definition of an OOP application as being a collection of objects that communicate with each other by sending messages.

A message is a request you send to an object in order to gain, give or process data.
When we say “send a message” to an object, what happens in reality is we make a call to a method which is part of the behaviour of that object.

The set of all the methods part of the definition of an object is often called ‘protocol’, and the collection of all the values’ attributes of an object is often referred to as ’state’.

So we can say that an object has a state and a protocol, both of which being defined in its abstract software representation (i.e. its class).

For example a Car Object can, in its class definition, have attributes such as color and speed, and methods to set and get such properties (setter and getter methods). An interesting property we might find in a Car object could be its engine. An engine is also an object, so in a real software application the engine property  will be a reference to an other object, establishing in this way the so called ‘has a‘ relationship (it is possible to say that a car  has an engine).

The engine variable for a Car object is not a common variable. Common data type such as an integers, double numbers, etc.  are data types available by default to a programming language and often called ‘primitive data types’.

Variables that hold objects (instances of a class) are not primitive data types; they are reference data types.
The difference between primitive and reference data types lays in the fact a computer stores them in memory diversely. Without going into too many details, the main difference is that for primitive data types the value assigned is stored directly in a block (or cell) of memory, while for reference data types the memory block simply holds an address that is a reference to the instance of a class.

An other type of relationship we can establish when programming in an object oriented manner, is the ‘is a‘ relationship. For a example a Ferrari (slurp) is a Car but with more specific attributes. If needed, a programmer can code a Ferrari class which extends the Car class. This way of creating inheritance between objects is a core concept of OOP .

There is of course a lot more to say about  inheritance, classes, objects, methods, etc… but I haven’t got anymore time right now… it is a world of fantasy in which I personally love to get lost in for hours. Give it a go if  you’ve never tried!

Thanks for reading.