Learn · OOP · Core
OOP — The 4 Pillars
Object-Oriented Programming means organising code around objects — bundles of data plus the actions on that data. Siemens always asks you to “explain OOP with an example.” After this, you’ll never fumble it.
Before we start
- What OOP is and why we organise code around objects
- The 4 pillars — each with a real example AND the code
- How they show up in Java and C#
- How to answer “explain OOP with an example” without freezing
- Explain the 4 pillars in your own words with examples
- Read and write the basic code for each pillar
- Model a real thing (like a payment) as classes
Why you’re learning it: OOP is half the MCQs and a guaranteed interview question — and it’s how real Java/C# codebases (including your Ayris one) are built. ⏱️ ~30 min.
First — what’s an object?
Think of a car. It has data (colour, speed, fuel) and actions (accelerate, brake, honk). An object bundles exactly that: data + the actions on it. A class is the blueprint (“Car”); an object is one built from it (“your red Swift”). OOP organises a program as objects talking to each other, instead of one long script.
Pillar 1 · 📦 Encapsulation
Bundle data + behaviour, and hide the internals. A BankAccount keeps its balance private — you deposit() or withdraw(), but you can’t just set balance = 1000000. The object guards its own data, like an ATM: buttons outside, cash logic locked inside.
class BankAccount {
private long balance; // hidden from outside
public void deposit(long amt) { balance += amt; }
public long getBalance() { return balance; }
}Pillar 2 · 🎛️ Abstraction
Show WHAT it does, hide HOW. You call list.add(x) without knowing it may be resizing an array underneath. Like a steering wheel — you turn it; you don’t think about the rack and pinion. Simple surface, complex insides.
Pillar 3 · 🧬 Inheritance
A class reuses and extends another. SavingsAccount extends Account — it gets deposit/withdraw for free and adds addInterest(). “A SavingsAccount is an Account, plus interest.”
class Account { void deposit(long a) { ... } }
class SavingsAccount extends Account {
void addInterest() { ... } // deposit() inherited for free
}Pillar 4 · 🎭 Polymorphism
Same call, different behaviour per object. Call shape.area() — a Circle computes πr², a Square computes side². Same method name, right answer for each type. The caller doesn’t care which.
Shape s = new Circle(); s.area(); // runs Circle's area() s = new Square(); s.area(); // same call, now runs Square's area()
Say it like this in the interview
“OOP bundles data and behaviour into objects. Encapsulation hides internals behind safe methods — a bank account guarding its balance. Abstraction exposes a simple surface and hides the how — a steering wheel. Inheritance lets a class reuse another’s code — a SavingsAccount is an Account with extra. Polymorphism lets the same call behave differently per type — shape.area() on a circle vs a square.”
Where you’ll use it — real life
Payment, Merchant, Transaction as classes with guarded fields — encapsulation and abstraction in your real job.
Beans, services, controllers are objects with clear jobs — OOP is the shape of every Java/C# backend.
Inheritance and interfaces let teams share code safely at scale.
Polymorphism lets you swap a SimBankAdapter for a RealBankAdapter with zero caller changes — your RupeeRail design.
Now YOU do the reps (design, not LeetCode)
OOP is practised by modelling. Do these on paper:
- Model a payment system: what classes? (Merchant, PaymentIntent, Ledger…) What data + methods does each own?
- Show encapsulation: which fields are private, what safe methods expose them?
- Show polymorphism: a
BankAdapterinterface with two implementations behaving differently.
Out loud, one real example each: “Explain encapsulation, abstraction, inheritance and polymorphism.” Fluent = interview-ready. Then log it in your Journal.
Related: C# (Java’s cousin) → · Back to your Siemens roadmap →