02. The OOP Lens: A Perspective, Not a Theory

If you’ve been following along from the last blog, we ended up somewhere around this thought:

“Okay… system design isn’t actually this scary, I had imagined.”

We broke things down. We took baby steps. We zoomed in and zoomed out. And eventually we reached Low Level Design.

Which sounds exciting…until you open any LLD resource and the first thing people tell you is:

“Before LLD, make sure your OOP concepts are strong.”

And if you’re anything like me, writing API endpoints in Express. Building React components. Connecting databases. Shipping features. Things were getting done. your immediate reaction might be:

“…why though?” I remember thinking this quite a lot. I wasn’t writing Java every day, except while solving leetcode.

I know what a class is. I knew an object is an instance of a class.

**I have probably answered interview questions like: **“Encapsulation means…”, “Inheritance means…”, “Polymorphism means…”

But none of that answered the actual question in my head:

“How has knowing OOP actually helped you build software?”

And honestly, the first version of almost every project feels amazing. Everything makes sense. The entire codebase lives comfortably inside your head. You know exactly where things are. You have a few APIs.

• Create order.
• Cancel order.
• Update inventory.
• Send notification

Life is good. You put some functions here. A few utility files there. Everything works. Then, slowly, reality starts happening.

PM asks:

• “Can we add refunds?”
• “Can we support payments from razorpay, paytm, upi, cards, stripe?”
• “Can sellers have different permissions than customers?”
• “What if notifications go through email, whatsapp, SMS, and push?”
• “What if inventory shouldn’t reduce until payment succeeds?”
• then discount coupons, then reward points, then premium membership and so on…

None of these requests sound unreasonable. In fact, they sound completely normal.

But somehow, after a few months, opening the same codebase starts feeling different.

You find yourself jumping between files trying to answer questions like:

“Wait…where does this logic live?”

“Why is this function changing three unrelated things?”

“If I change this piece of code, what else am I accidentally breaking?”

”Who is responsible for changing the order status?”

“Why does this payment code know so much about order?”

“Who thought this was a good idea?”

And somewhere around this point, OOP started making a little more sense to me.

Instead of treating the entire application as one big pile of functions, OOP asks us to think a little differently.

It says: “What are the actual things that exist in this system?”

In an e-commerce application, maybe there is an Order. Maybe there is a Payment. Maybe there is an Inventory. Maybe there is a Notification.

And each of these things should be responsible for its own work.

• An Order shouldn’t know how to send emails.
• A Notification shouldn’t decide whether inventory should decrease.
• A Payment shouldn’t randomly change order statuses.

Everyone should mind their own business.

Now you may say :-

“Okay…but if everyone is independent, how does an application actually work?”

And that’s a very fair question. Because OOP isn’t asking us to isolate everything and pretend the other pieces don’t exist.

For example, imagine a customer placing an order:

Customer places an order
        ↓
Order asks Payment to process the amount
        ↓
Payment confirms success
        ↓
Order asks Inventory to reserve the items
        ↓
Inventory updates stock
        ↓
Notification informs the customer

If you look at this flow carefully, nobody is trying to do someone else’s job.

• The Order isn't calculating payment gateway fees.
• The Payment isn't reducing stock.
• The Inventory isn't sending emails.

Each component focuses on what it knows best. Yet together, they create a complete experience for the customer.

And maybe that’s the real beauty of OOP. OOP is really teaching us a way of thinking:

Break your software into independent pieces with clear responsibilities, and then build meaningful relationships between those pieces and make them collaborate without creating chaos.

And if you think about it…isn’t that exactly what we’ve been doing since the first blog of this series?

• We took a huge system.
• We broke it into components.
• We gave each component a responsibility.
• And then we thought about how they communicate.

OOP simply brings that same thinking one level closer to the code.

That’s why, before we jump into design patterns and LLD, we need to build one important lens.

The OOP lens.

All the examples we imagined today — the Orders, Payments, Inventory, Notifications — they weren’t just examples.

They were a glimpse into the way OOP encourages us to think about software.

Today, we didn’t learn Encapsulation. We didn’t learn Inheritance. We didn’t learn Polymorphism. We didn’t even write a single class. And that was intentional.

Everything we discussed today was really about the why behind OOP. Why responsibilities matter. Why boundaries matter. Why collaboration matters. But eventually, this way of thinking has to move from our heads into our code. The core concepts of OOP are what make that possible.

And that’s where our journey continues in the next blog.