Sanudin Logo
← Back to blog

OOP for Everyone: Blueprints, Robots, and the 4 Pillars Explained Simply

Series: Clean Code from the Ground Up Part 1 of 4 — Object Oriented Programming 🕐 ~5 min read · Beginner friendly

📝 A note on this article This post is based on my personal study notes on OOP and SOLID principles. To make these notes more readable and useful — for myself and for others — I worked with AI to help expand and structure them into a proper blog format. The ideas, learning journey, and understanding are mine; the AI helped with the writing and presentation.

If you've ever built something with code — even just a small script — you've already felt the pain that Object Oriented Programming (OOP) tries to solve.

Your code grows. Things get messy. You change one thing and something else breaks. Sound familiar?

OOP is one of the most popular ways to bring order to that chaos. And the best part? It's designed to mirror the real world. Which means if you can explain it to a kid using toys, you already understand it.

Let's do exactly that.

First: What Even Is a "Programming Paradigm"?

Before we get to OOP, let's clear up one term: paradigm.

A programming paradigm is just a style of writing code. Think of it like cooking styles — some people cook everything in one pot, others prep every ingredient separately before combining. Both approaches work, but they suit different situations.

OOP is one such style. And it's been the dominant one in software development for decades.

So, What Is OOP?

Object Oriented Programming (OOP) is a programming approach where you organize your code around objects — things that have both data (what they are) and behavior (what they do).

Here's the real-world parallel:

🤖 Imagine a robot toy. It has properties — color, height, battery level. And it has behaviors — it can walk, talk, and wave. In OOP, that robot is an object.

Now imagine you want 10 robots, all slightly different. You wouldn't build each one from scratch. You'd use a blueprint.

In OOP, that blueprint is called a class.

Classes and Objects

  • A class is the blueprint — the template that defines what an object looks like and what it can do.
  • An object is an instance of that class — an actual robot built from the blueprint.
Class: Robot
├── Properties: color, height, battery
└── Behaviors: walk(), talk(), wave()

Object 1: redRobot  (color: red, height: 30cm)
Object 2: blueRobot (color: blue, height: 45cm)

Both redRobot and blueRobot are built from the same Robot class. Same structure, different data.

Inside a class, you'll find:

  • Properties — the data (color, height, battery level)
  • Functions/Methods — the behaviors (walk, talk, wave)

The Four Pillars of OOP

OOP stands on four fundamental ideas. Each one solves a specific problem that comes up as your code grows.

1. Inheritance — "Like parent, like child"

Inheritance lets a new class inherit the properties and behaviors of an existing class.

🏠 Think of it like a family home. The kids inherit the house's address, its layout, the keys. But each child can also have their own room, decorated differently.

In code, the original class is called the superclass (or parent class), and the new one is the subclass (or child class).

There are a few types of inheritance:

  • Single — one child, one parent
  • Multiple — one child, many parents
  • Hierarchical — one parent, many children
  • Hybrid — a combination of the above

The key benefit: you write shared logic once in the parent, and all children get it automatically.

2. Encapsulation — "What happens inside, stays inside"

Encapsulation means bundling data and the functions that work on it into a single unit (a class) — and hiding the internal details from the outside world.

🎮 Think of a game controller. You press a button and something happens. You don't need to know the circuits inside. The internals are hidden — only the buttons are exposed.

This protects your data. Other parts of the program can't accidentally reach in and mess with values they shouldn't touch.

3. Abstraction — "Show only what's needed"

Abstraction is about hiding complexity and only showing what's relevant to the user of a class.

☕ A coffee machine has dozens of internal processes — water heating, pressure building, grinding. But all you see is: press a button, get coffee. The complexity is abstracted away.

While encapsulation hides data, abstraction hides implementation. Together they keep your code clean and easy to use.

4. Polymorphism — "Many forms, one interface"

Polymorphism means the same action can behave differently depending on the object.

🐾 A dog and a cat both speak. But a dog says "woof" and a cat says "meow". Same action (speak()), different result.

There are two types:

  • Compile-time polymorphism — the right behavior is decided when the code is compiled (e.g., function overloading: same name, different parameters)
  • Runtime polymorphism — the right behavior is decided when the code is running (e.g., method overriding: child class changes the parent's behavior)

Why Does This Matter?

Here's the honest answer: OOP isn't magic. It's a set of conventions that — when followed — make code easier to:

  • Read — because the structure mirrors real-world concepts
  • Change — because responsibilities are clearly separated
  • Reuse — because you build once and inherit many times

But OOP is just the foundation. There's a whole layer of design principles on top of it — rules that help you use OOP well, not just technically.

That's what the rest of this series is about.

What's Next?

In the next article, we'll look at how objects talk to each other — the different types of relationships between classes, and why getting them right matters more than most developers realize.

→ Part 2: How Objects Relate — Association, Aggregation & More

📌 Series overview:

  • Part 1: What is OOP? ← you are here
  • Part 2: How Objects Relate to Each Other
  • Part 3: Why Bad Design Hurts — Software Design Principles
  • Part 4: SOLID — 5 Rules for Writing Clean, Maintainable Code