Abstraction Process, Encapsulation, Information Hiding,

and Modularity

Object-oriented programming rests on four essential pillars, which are:

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

Now that we know about abstraction, let’s delve into the abstraction process and the role
encapsulation has in OPP.

Abstraction and Abstraction Process

As we have learned previously, abstractions are the models we have in the reality
surrounding us. On the other hand, the abstraction process is the series of actions we
carry out to give shape to reality and to tell the program with which classes (thus, the
objects) it will be working. This process is commonly referred to as “modeling”.

Through the abstraction process, we aim to obtain “a model” of reality. This process not
only includes thinking about the models to be used but also considering how these will
interact among themselves. Additionally, we must take into account the context in which
our models will operate. The abstraction process must answer questions such as:

1. What models do I need? What classes must be defined?

2. How will objects interact among themselves? What public interface does each one
have?
3. What is the problem to be solved? In what context will my objects work?

While there may be more questions to answer, these three points are essential.
Particularly the one related to context, which is one of the most important since it will
have an impact on the way we preview the models.

For example, let’s suppose we want to model a system for a person. What problems will
the system have to solve? Let’s focus on an interactive simulation system for general
medicine students. The person in this context will have many attributes, such as age,

© Universidad de Palermo. No part of this publication, either text or images can be reproduced.

PA
weight, gender, organs, systems, symptoms, sugar levels, cholesterol levels, disease
history, etc. The level of detail can be quite high. The problem to be solved is how,
according to the person’s characteristics and symptoms, students are able to reach a
certain diagnosis.

Now, let’s pretend we want to make a list of people for salary payments. Our abstraction
of a person can be as simple as name, age, time in the company, salary, benefits, and ID.
Height, gender and weight are of no consequence in this context. If I want to elaborate on
said list, I would not actually need all the additional data in the model.

The modeling process strictly depends on the problem to be solved, i.e. the context. This
is commonly referred to as the problem “domain” or “business”.

Encapsulation
Abstractions define models, i.e. the classes we will be using. Further to defining attributes,
classes define behaviors. Behavior indicates how the objects will interact among
themselves and we know that the behavioral set is called “public interface.” This term is
not random, since objects may have behaviors that do not necessarily affect other objects.

Going back to the three points mentioned before (the questions), the abstraction process
must include also another key question: Which operations must be public and which
should not? This is the moment concepts such as encapsulation and information hiding
become important.

There has been some controversy among authors and scholars on the object-oriented
paradigm to settle on a definition for both terms, as well as to determine the limit of the
relationship between the two concepts.

Regarding simplicity, Rebecca Wirfs-Brock view is particularly interesting. She is a

renowned software engineer who has dedicated many years to analyzing software design.
She considers encapsulation as the simple fact of putting data, and related operations on
these data, in an only entity or “capsule.” By her definition, encapsulation means simply
“group” data and the related operations in an only container.

In a structured programming language, we find data on one side and operations on the
other. In other words, structured languages operate with functions or routines over data
structures. Routines are stored in a position of the memory whereas data is located in

© Universidad de Palermo. No part of this publication, either text or images can be reproduced.

PA
another position. This means that routines depend on data structures for proper
functioning.

In an object-oriented language, data go hand in hand with operations, as if data structures

and routines were together. This is just a concept since everything is separate hardware-
wise. The memory will store operations separate from data, but the object-oriented
paradigm conceives it together since it intends to model reality, which up to a certain
extent can be very convenient. In other words, we conceive things as entities with
attributes (with quantitative values) that perform operations (do things).

For example, Bobby, the neighbor’s cute dog, in OPP can be viewed as a “dog object”, a
brown fur that barks and wags its tail. As people, we will never perceive the neighbor’s
dog as a data structure consisting of a chain of characters for its name, a number
representing a color, with a card containing instructions to wag its tail or bark. Certainly
not. For us, the dog is a whole entity that does whatever dogs do and carries its data and
operations within the entity.

In Java, we encapsulate using classes. Other languages may have other encapsulation
methods. Java classes represent the minimal expression of encapsulation. But take into
consideration that we also have the possibility of encapsulating bigger entities: we can
encapsulate functionality behind a sub-system made up of a myriad of classes, or we could
have functionality encapsulated behind a system conformed by sub-systems made by
classes, etc.

Information Hiding
Hiding information does not mean simply hiding it from the rest of the objects. The idea
supporting information hiding is to provide a controlled mechanism to access the values of
the object’s attributes. Controlling access is not exclusively associated with security.
Control means that, before obtaining a value or changing a value, we can execute an
action, perform a calculation or additional checks, etc.

During the abstraction process we must decide how data will be accessed and/or how it
will be modified: should we allow access to data freely or should we make it accessible
only through an operation? For example, if we make any change in data (e.g. a date) it
changes from being an integer to being a Date type datum. Access to that piece of data
using an operation that returns a text value with a certain date will never be affected.

© Universidad de Palermo. No part of this publication, either text or images can be reproduced.

PA
We can say that information hiding is the mechanism through which we obtain
encapsulation. Sometimes these concepts are misperceived, but not everything that is
encapsulated will be hidden.

Let’s imagine an object “Sales representative” that interacts with the object “Person.” The
sales representative object will interrelate with the person object and will inquire, for
instance, an age, executing his method “tellAge().”. The sales representative object does
not mind if the person object keeps a year counter or if it saves the birth date and
subtracts the current date. How the age value is achieved is not relevant, the value is the
result of the operation “tellAge.” In this way, the age in the person object is not hidden
but it is encapsulated. We can know the person’s age, but we don’t know how it was
calculated.

David Parnas, a renowned pioneer in software engineering, with a PhD from Carnegie
Mellon, developed the concept of information hiding. According to him, anything that is
exposed should reveal as little as possible of the internal functioning of an object.

Modularity
Parnas was an adamant supporter of software modules, being one of the first to apply
engineering concepts to software design. His idea supporting software modularity is that
thanks to an appropriate use of information encapsulation and hiding, we can manage to
split software into interchangeable modules. Parnas believed that achieving software with
parts sufficiently self-contained in which changes in one would not negatively impact, or
the effect would be minimal, on the other was a great advantage. The engineer in him
aimed at making software parts as easily replaceable as engine spare-parts are.

Modularity pursues just that, being able to divide software in such a way that we can
interchange parts without disturbing others. It should not be understood just as the
creation of a module-based system; a module can embody an entire system in itself, a
module can be a subsystem or, even further, a module can be only a class.

Modular design implies a low interrelation among modules which means modules should
be as self-contained as possible. Keeping this in mind will help us get familiarized with
cohesion and coupling concepts.

© Universidad de Palermo. No part of this publication, either text or images can be reproduced.

PA
To reflect

Do you think information hiding is beneficial?

Do you believe having the status and behavior of a public object would make things
easier?

What disadvantages do you foresee?

© Universidad de Palermo. No part of this publication, either text or images can be reproduced.

PA