Java, OOP, and the Steady Path Forward

Hey Devs 👋

This week, I stepped deeper into Java and OOP — not just as part of my university module, but also as a way to stay grounded while dealing with personal grief.

I’ve been reviewing topics like:

• What is OOP?
• Classes, objects, and visibility in Java
• Constructors, getters, setters
• The beginnings of encapsulation

And to bring it all together, I built a simple Java project modelling a bank account. Private balance, public methods, account types, deposits, withdrawals, and realistic conditionals (sadly no “print transaction confetti” yet).

Progress is slow, but it’s progress. Sometimes code gives you structure when life doesn’t.

Java, OOP, and the Steady Path Forward

It’s been a heavy couple of weeks. I won’t pretend otherwise. But in the quiet moments between the waves of grief, I’ve found some comfort in structure, and there’s no better structure right now than Java’s object-oriented programming model.

I’ve just started my Object-Oriented Programming (OOP) module at university, all Java-based, and alongside it, I’m taking an extra course to make sure I really absorb the concepts, not just pass the module. Slow and steady. Not moving on, but moving forward.

And while many of the topics feel familiar (I’ve seen them before in my earlier dev journey), Java’s strictness, clarity, and obsession with visibility have given me a sharper lens on how it all fits together.

What I’ve Been Studying

Here's a quick list of what I’ve covered so far:

• What is OOP? A programming paradigm that thinks in terms of objects, not just functions and data.
• What is an Object? Not just “a thing”, but a bundle of state and behaviour. Like a dog, or a bank account. (One hurts a bit more to talk about right now.)
• Classes and Objects in Java Classes are blueprints. Objects are the real-world instances. I’ve seen this concept before, but Java really leans into it with its strong typing and access control.
• Visibility of Objects and Members Java makes you choose: public, private, protected. Every attribute and method must wear a name tag that says who can interact with it.
• Special Methods Constructors, getters, setters. The behind-the-scenes machinery that keeps your objects sane and your access clean.

My Practice Project: The Bank Account Class

To bring it all together, I built a basic BankAccount class, the kind of exercise that’s simple enough in theory, but full of edge cases once you really start thinking like a developer.

Each account holds state (like balance, owner, account type) and methods to act on it, deposit, withdraw, open/close, pay fees.

It’s satisfying to see how encapsulation comes into play. Want to mess with the balance directly? Too bad, it’s private. Use the method like a respectful developer, please.

The logic starts to look real: conditionals for insufficient funds, fees based on account type, message outputs that sound a little too realistic for some of the bank branches I’ve dealt with.

I even added a currentStatus() method to print out everything about the account, because debugging is easier when your objects talk back.

What’s Next

Next stop: Encapsulation, in full. I’ve already dipped into it, but the next lessons will take a deeper dive into how Java uses access modifiers to protect data, enforce behaviour, and encourage cleaner code.

And honestly, I’m looking forward to it.

Right now, having something to structure my time, focus my energy, and remind me of progress, no matter how small, is incredibly grounding.

Final Thoughts

It’s a strange comfort to return to code when life feels uncertain. OOP is, in a way, about containment, wrapping up state and logic so things behave predictably. And that predictability is a relief right now.

I’m learning, I’m building, and I’m still here... one class, one object, one method at a time.

Let me know how OOP made sense to you — or what helped it finally click 👇