Abstraction: Classes, objects and instances

Object-Oriented Programming, or OOP for short, tries to mimic reality, in code.

OOP somewhat “speaks the language” humans do. It understands software entities as
“things” (objects) that “perform actions”, contrary to the structured programming
paradigm that deals with data abstract structures and routines or functions that operate
on the data.

Object-oriented programming has four main pillars:

1. Abstraction
2. Encapsulation
3. Inheritance
4. Polymorphism

Each one of these, complex as they may seem, are nothing more than concrete features of
the things that are around us. Let’s begin exploring the first pillar: Abstraction.

Abstraction
Abstraction means to capture the essence of something. That is, look at the things around
and make a mental model of them:

 What are the characteristics or attributes of this thing?

We can recognize everything around us thanks to the mental models that we have
created. But, when we sit down in front of the computer we have to, somehow, tell it
what those models are.

Classes

In OOP we use classes as the basic form of telling the computer what those models are,
how to represent them, and which are their features.

© Universidad de Palermo. Prohibida la reproducción total o parcial de imágenes y textos.

PA
When we define a class, we define a template, a model, the “idea” of something, i.e. “an
abstraction”. Once we have a class defined, we code it into our program. In the real world,
we can get concrete stuff from a model. In the software world, we can do the same, we
can obtain concrete objects from classes.

For example, let’s picture the blueprints of a pre-fabricated or modular house: each time
we want to build a house, we follow the blueprints, we follow the distances, we follow the
instructions, we respect the materials and quantities, ending up with a newly built house.
The architect or designer surely included what the house does, like dissipating heat in the
summer, and even how to collect sunlight in order to have power for the household
appliances. The same thing goes for classes: classes define attributes or features it has
and also define the operations the model should carry out, i.e. how it should behave.
Some of these operations are called “constructors”, used specifically to build new objects
from the template. Just like the operation we perform to build a house from the
blueprints.

Objects

Things around us, the real world objects, share two unquestionable features:

1. They all have measurable values

If all objects derive from a model, then that model must have defined the attributes and
the possible operations to perform. So, if we get objects from a class, then the class is
what defines the attributes and operations.

Contrary to classes, objects are not abstract, but totally concrete. They respect the
attributes defined in the model (the class says what an object should have) and have
(store) concrete values for each attribute. The set of values of the object’s attributes is
called “internal state”.

For example, a house should have certain attributes, one of them being the interior
temperature. If our model is for a sustainable house, the interior temperature should be
in a certain range. Now let’s picture the house with a northern-southern orientation,
where its temperature is at 18°C. If we make another house from the same blueprints,
with the same materials and quantities, but with an eastern-western orientation, the
result will differ. In our second house, because of how the sunlight reflects in it, the

© Universidad de Palermo. Prohibida la reproducción total o parcial de imágenes y textos.

PA
temperature is of 20°C. Both houses are basically the same, but they hold different values
in their “interior temperature” attribute.

In OOP, an object is a piece of software that relates internal state with behavior. The
house, for example, has an internal state: orientation, location, interior temperature,
exterior color, etc., and has a certain behavior: it can heat up and cool down. In other
words, an object “holds state” storing values in its attributes and “exposes behavior”
through its operations, which are called “methods”. The exposed behavior is known as
“interface”, or more specifically “public interface”, as it is well exposed. Public interfaces
make up the whole set of operations on an object that other objects can execute on it. If
this house was part of a simulation, an object “sun” could heat up another object “house”,
executing its operation “increase interior temperature” exposed by the “house” object
that is defined in the “House” class, from which we derive all the possible “house” objects.

Instances

By definition, an object is an instance of a class. This means that each time we construct
an object, we obtain a new instance. Meaning that, there is a difference between an
object and an instance. Knowing that for each object we create a new instance, we can
understand that each instance will be unique and unrepeatable.

With each new instance, we obtain a new object and this object will store values in its
attributes. So, even if I make two houses, painted in white, northern-southern oriented,
located in the same neighborhood, I could not say I have two identical houses. The correct
answer will be that I have two equal house objects that store the same values in their
attributes. Having two equal house objects does not mean we have the same instance of a
house twice.

This correlates with nature, if two objects were exactly the same, they would occupy the
same physical space, they would be placed in the exact same spot, they would have the
same molecules, particles, etc., and we know that’s impossible (two things cannot be at
the same place at the same time). This also has a correlation with the software world, and
even more so, in the hardware world, if two objects were exactly the same, it would mean
they are stored in the same position in memory (it would be like trying to put one house
right where the other house is) and we cannot store two different things in the same
position in the computer’s memory, much less at the same time.

© Universidad de Palermo. Prohibida la reproducción total o parcial de imágenes y textos.

PA
This is why instances introduce the concept of “identity”. There can be two equal objects,
but they cannot be identical. Instances are unique and unrepeatable, and with each
object we construct, we will have a new instance. Therefore, there will be no other
instances identical to those that existed before.

For example, I could have two white houses, north-south oriented, with their interior
temperature exactly at 20°C, and located in the same neighborhood. However, they would
not be the same house. There is always something that distinguishes one house from the
other, like an address. Each house will have a specific address. Otherwise, and again, it
would be another house, somehow constructed in the same place as the first one, and
that is not possible.

In case this situation does happen, it does not contradict the principle of identity. There
may be a user error, where the person in charge just sets the same value of the address
attribute of the two houses. But, when running the program, the explained thing will
happen. I might have two equal house objects, with the same values in their attributes,
but each will create a separate instance.

The conclusion here is that there might be two equal objects, but that does not mean they
are the same. They are not necessarily identical. On the contrary, if two objects are
identical, then they would be equal, because it means they are the same instance.

To reflect

Now try to picture two identical objects that are not equal and two equal objects that are
not identical. This is an interesting exercise to start identifying objects and instances in
nature and in code.

© Universidad de Palermo. Prohibida la reproducción total o parcial de imágenes y textos.

PA