Hello IT World! Why I’m "Learning in Public" at sandycodesdev 🚀

 Demystifying OOP: What on Earth is Abstraction? 🛠️

Hey guys! Welcome back to sandycodesdev. 🚀

These days, I am actively preparing myself for my upcoming software engineering internship interviews. Because of that, I’ve been making sure I actually understand Object-Oriented Programming (OOP).

Let’s be honest, most of us IT students "know" what OOP is. We have memorized tons of academic definitions just to pass our university exams. But if someone asked you right now to explain it, do you really have the confidence to do it?

If you do, that's awesome! This post might not be for you. But if you're like most students who feel a bit shaky when moving past basic definitions, let's break it down together.

🛑 Life Before OOP: The "Spaghetti Code" Nightmare

Before we look at the main parts of OOP, let's answer a massive question: Why do we even need OOP? What happens if we don't use it?

Without OOP, we write what is called Procedural Programming. This just means your code is one long, continuous list of instructions. Functions run one after another like a simple checklist. When your project is small, it works fine. But the moment your project grows, your code becomes a giant, tangled bowl of spaghetti.

Let's look at a practical example. Imagine we are building a simple system to start different types of vehicles without using OOP:

Why is this "No-OOP" code terrible?

1. It's Fragile (Easy to break): If we need to add a Truck, a Bus, and an ElectricScooter tomorrow, we have to keep changing that original startVehicle method with endless else if statements.
2. Zero Organization: There is no clear plan. The data (the vehicle name) and the action (how it starts) are completely separated and floating around untamed.

To fix this mess, software engineers use Classes and Objects. A Class is just a clean blueprint (like the drawing of a car) and an Object is the real thing built from that blueprint (the physical car you can drive).

When I searched for ‘what are the OOP concepts use in Software Engineering’, I realized everything in OOP stands on 4 major pillars. Today, let's look at how the very first pillar, Abstraction, beautifully changes our messy spaghetti code into clean code.

☕ The Real-World Analogy: The Coffee Machine

Academic textbooks love to throw around confusing definitions for Abstraction, like: 

"The process of hiding the implementation details and showing only the functionality to the user."

English please! Let's think about a real coffee machine instead. You walk up to it, press a button labeled "Cappuccino," and a minute later, you have a hot drink.

Do you need to see the internal pipes? Do you need to calculate the water pressure or know how fast the grinder spins?

Absolutely not. All of that messy, complicated machinery is hidden behind a simple, friendly interface: a button. That is Abstraction. It separates what you want to do from the complex details of how it actually happens.

 

💻 The Rescue: Rewriting Our Code With Abstraction (Java)

Let’s apply Abstraction to our messy vehicle code using Java's abstract class. We will hide the complicated details and give our system a clean, simple setup:

 

Now, instead of one giant method with a million if/else conditions, each vehicle safely takes care of its own starting details:

 

🎯 The Practical Magic: Why Recruiters Care

Look at how beautiful and simple our main system code becomes now because of Abstraction: 

If your interviewer asks you why this OOP approach is better, give them this simple answer: 
It grows easily without stress.

If we need to add a Truck class tomorrow, we never touch our main code logic again. We don't write any new if/else statements. We just create a new Truck class that connects to Vehicle, and our operateVehicle method handles it perfectly. Our existing code stays 100% safe, clean, and untouched.

🏁 Summary Checklist for Your Next Interview

When an interviewer asks you about Abstraction, just remember the coffee machine checklist:

• The Problem: Without OOP, code becomes a messy, fragile web of if/else statements.
• The Solution: Abstraction cuts down confusion by hiding the complicated background machinery.
• The Practice: It separates what an object does from how it does it using abstract classes and interfaces.

What do you think, guys? Does seeing the code before and after OOP make Abstraction easier to understand? Let me know in the comments how you are using abstract classes in your own university assignments!

Until the next push,

Sandy 👨‍💻