Abstraction: The Forgotten Child of OOP

Abstraction as a concept is easier to implement than it is to explain. Most trainers at the college level never bother to get into the need and benefits of a feature of technology. 

When I was talking to a friend from the industry, I came across a startling fact — they rarely use abstraction!

One of the reasons I think Abstraction has a bad name is because it is a lot easier to implement in Java than to understand it thoroughly.

So, through this article, I am trying to throw some light on what exactly abstraction means. 

Why Is Abstraction in Software Important?

If you have ever worked in a team, you will understand this point easily. Every team member has a defined role, and some important roles require multiple team members.

Consider this situation: Sara, Peter, and Jack are a part of Application Processing Team at a large conference. Let’s call them Person 1 (Sara), Person 2 (Peter), and Person 3 (Jack) for the sake of understanding this.

Because they are all working toward a common goal, they will be sharing some information, which will be the application form. They can pass this form in stages from one member to another. For example, Sara (Person 1) enters the form data into the software, Peter (Person 2) approves/rejects the application and Jack (Person 3) processes the accepted entries. This is the normal scenario and has been working well.

But if Peter also performs the role of an application processor, both Peter and Jack (Person 2 and 3) will be working on processing the approvals. All this while Peter (Person 2) is simultaneously allocated to approving/rejecting the entries. This slows down the entire application process.

It was working fine until we added some extra responsibilities for Person 2 (Peter) and caused an extra burden of unplanned work on one of the people involved in application processing.

Imagine these people involved in application processing are like the modules in your application. If a software module shares its functions and processing with other modules, it will result in one royal mess of a code. And by this, I mean when you try to update one module, the complex dependency links among the code will cause those changes to be reflected in other modules also. This is a ripple effect.

In software, applications do not die. They are upgraded every few years. Some technical architects like to keep them updated every quarter. Often, business owners will request a change or addition of a new feature. Whatever the updating frequency, making changes in multiple modules all the time will only slow it down. And we do not want that!

The dependence among application modules cannot be more than what is absolutely essential. One module should do ONLY one task, and do it as much independently as possible.