OOP Concepts Every Developer Should Master in 2026

Here’s a confession: I used to think I understood OOP because I could define a class and create objects. Then I tried to design a chess game in an interview and realized I had no idea how to model pieces, boards, moves, and rules as a system of interacting objects.

Knowing the syntax of OOP isn’t the same as thinking in objects. And in 2026, with LLD interviews becoming standard at every major tech company, the gap between “I can write a class” and “I can design a system” has never mattered more.

This guide covers the OOP concepts that actually matter—not textbook definitions, but the practical skills you need to build clean, extensible software and ace design interviews.

The 4 Pillars of OOP (With Real Analogies)

You’ve seen these four words a thousand times. Let’s make them stick—not with textbook definitions, but with mental models you’ll actually remember.

1. Encapsulation: The ATM Machine

The analogy: An ATM lets you withdraw money, check your balance, and deposit cash. But you can’t reach inside and grab bills directly. You interact through a defined interface (the screen and buttons), and the internal mechanism is hidden.

In code terms: Encapsulation bundles data and the methods that operate on that data into a single unit (a class), and restricts direct access to the internal state.

1
class BankAccount:
2
    def __init__(self, owner: str, balance: float = 0):
3
        self._owner = owner          # protected
4
        self.__balance = balance     # private
5

6
    def deposit(self, amount: float) -> None:
7
        if amount <= 0:
8
            raise ValueError("Deposit must be positive")
9
        self.__balance += amount
10

11
    def withdraw(self, amount: float) -> None:
12
        if amount > self.__balance:
13
            raise ValueError("Insufficient funds")
14
        self.__balance -= amount
15

16
    @property
17
    def balance(self) -> float:
18
        return self.__balance
19

20
# Usage
21
account = BankAccount("Alice", 1000)
22
account.deposit(500)       # ✅ Uses the controlled interface
23
account.withdraw(200)      # ✅ Validates before acting
24
print(account.balance)     # ✅ Read-only access via property
25
# account.__balance = 999  # ❌ Can't manipulate directly

Why it matters: Without encapsulation, any piece of code can modify any data, creating bugs that are impossible to trace. Encapsulation creates trust boundaries—you know that balance can only change through deposit() and withdraw(), both of which validate the operation first.

The most common mistake: Making everything public “for convenience.” If every field is public, you have a struct, not an object. The moment you need to add validation or logging, you’ll have to find and update every place that directly modifies the field.

Deep dive: Encapsulation

2. Abstraction: The Car Dashboard

The analogy: When you drive a car, you use the steering wheel, pedals, and gear shift. You don’t need to understand how the engine combustion cycle works, how the transmission converts gear ratios, or how the anti-lock braking system prevents wheel lockup. The car abstracts the complexity behind a simple interface.

In code terms: Abstraction means exposing only what’s necessary and hiding the implementation details. In Python, this is typically done with abstract base classes:

1
from abc import ABC, abstractmethod
2

3
class NotificationSender(ABC):
4
    """Users of this class only need to know about send().
5
    They don't care HOW the notification is delivered."""
6

7
    @abstractmethod
8
    def send(self, recipient: str, message: str) -> bool:
9
        pass
10

11
class EmailSender(NotificationSender):
12
    def send(self, recipient: str, message: str) -> bool:
13
        # Complex SMTP logic hidden here:
14
        # connect to server, authenticate, format MIME,
15
        # handle attachments, retry on failure...
16
        return self._send_via_smtp(recipient, message)
17

18
    def _send_via_smtp(self, to: str, msg: str) -> bool:
19
        # 50 lines of SMTP details nobody else needs to see
20
        ...
21
        return True
22

23
class SMSSender(NotificationSender):
24
    def send(self, recipient: str, message: str) -> bool:
25
        # Twilio API integration hidden here
26
        return self._send_via_twilio(recipient, message)
27

28
    def _send_via_twilio(self, to: str, msg: str) -> bool:
29
        ...
30
        return True

Why it matters: Abstraction lets you think at the right level. When designing a notification service, you think about “send a notification”—not “connect to an SMTP server on port 587, authenticate with TLS, format a MIME multipart message…” Abstraction manages the cognitive load of complex systems.

Deep dive: Abstraction

Encapsulation vs Abstraction: The Most Confused Pair

These two get mixed up constantly. Here’s the clearest distinction:

The one-liner: Encapsulation is about protecting data. Abstraction is about hiding complexity. A class can (and usually should) use both.

3. Inheritance: The Shape Hierarchy

The analogy: In biology, a German Shepherd inherits traits from the broader Dog category, which inherits from Mammal, which inherits from Animal. Each level adds specialization while keeping the general traits.

In code terms: Inheritance lets a class (child) derive from another class (parent), inheriting its attributes and methods while adding or overriding its own:

1
class Shape:
2
    def __init__(self, color: str):
3
        self.color = color
4

5
    def area(self) -> float:
6
        raise NotImplementedError
7

8
    def describe(self) -> str:
9
        return f"A {self.color} {self.__class__.__name__} with area {self.area():.2f}"
10

11
class Circle(Shape):
12
    def __init__(self, color: str, radius: float):
13
        super().__init__(color)
14
        self.radius = radius
15

16
    def area(self) -> float:
17
        return 3.14159 * self.radius ** 2
18

19
class Rectangle(Shape):
20
    def __init__(self, color: str, width: float, height: float):
21
        super().__init__(color)
22
        self.width = width
23
        self.height = height
24

25
    def area(self) -> float:
26
        return self.width * self.height
27

28
# Both work as Shape
29
shapes: list[Shape] = [Circle("red", 5), Rectangle("blue", 4, 6)]
30
for shape in shapes:
31
    print(shape.describe())
32
# "A red Circle with area 78.54"
33
# "A blue Rectangle with area 24.00"

Why it matters: Inheritance enables polymorphism (Pillar 4), allows code reuse, and models “is-a” relationships naturally. A Circle is a Shape. A SavingsAccount is a BankAccount.

The danger: Inheritance is the most overused OOP feature. Deep hierarchies (5+ levels) become rigid and hard to change. A common rule of thumb: if you’re inheriting just for code reuse, you’re doing it wrong. That’s what composition is for.

Deep dive: Inheritance

4. Polymorphism: The Universal Remote

The analogy: A universal remote has a “power” button that works with your TV, sound bar, and streaming box. The same button, different devices, different behavior. The remote doesn’t need to know how each device turns on—it just sends the signal.

In code terms: Polymorphism means “many forms”—the same interface (method name) behaves differently based on the object’s type:

1
class PaymentMethod:
2
    def pay(self, amount: float) -> str:
3
        raise NotImplementedError
4

5
class CreditCard(PaymentMethod):
6
    def pay(self, amount: float) -> str:
7
        return f"Charged ${amount:.2f} to credit card"
8

9
class UPI(PaymentMethod):
10
    def pay(self, amount: float) -> str:
11
        return f"Transferred ${amount:.2f} via UPI"
12

13
class Crypto(PaymentMethod):
14
    def pay(self, amount: float) -> str:
15
        return f"Sent {amount / 50000:.6f} BTC"
16

17
def checkout(method: PaymentMethod, amount: float):
18
    # This function doesn't know or care which payment type it is
19
    print(method.pay(amount))
20

21
# All work through the same interface
22
checkout(CreditCard(), 99.99)   # "Charged $99.99 to credit card"
23
checkout(UPI(), 99.99)          # "Transferred $99.99 via UPI"
24
checkout(Crypto(), 99.99)       # "Sent 0.002000 BTC"

Why it matters: Polymorphism is the foundation of the Strategy pattern—the single most used pattern in LLD interviews. Every time you see “swap algorithms at runtime” or “support multiple types,” you’re using polymorphism.

Python’s superpower—Duck Typing: In Python, you don’t even need inheritance for polymorphism. If an object has a pay() method, it works—regardless of its class hierarchy. “If it walks like a duck and quacks like a duck, it’s a duck.”

1
class Cash:  # No inheritance!
2
    def pay(self, amount: float) -> str:
3
        return f"Paid ${amount:.2f} in cash"
4

5
checkout(Cash(), 99.99)  # Works perfectly in Python

Deep dive: Polymorphism

Class Relationships: The Part Most Developers Skip

Knowing the 4 pillars is necessary but not sufficient. The real skill is knowing how classes connect to each other. This is where most LLD designs succeed or fail.

Association: “Uses” or “Knows About”

A Doctor treats a Patient. They interact but exist independently. Neither owns the other.

1
class Doctor:
2
    def __init__(self, name: str):
3
        self.name = name
4

5
    def treat(self, patient: "Patient") -> str:
6
        return f"Dr. {self.name} treats {patient.name}"
7

8
class Patient:
9
    def __init__(self, name: str):
10
        self.name = name

The doctor and patient have their own lifecycles. Deleting the doctor doesn’t delete the patient. This is the loosest relationship.

Deep dive: Association

Aggregation: “Has, But Doesn’t Own”

A Department has Employees, but employees exist even if the department is dissolved. The department doesn’t control their lifecycle.

1
class Department:
2
    def __init__(self, name: str):
3
        self.name = name
4
        self.employees: list[Employee] = []
5

6
    def add_employee(self, employee: "Employee"):
7
        self.employees.append(employee)
8

9
# Employees exist independently
10
alice = Employee("Alice")
11
bob = Employee("Bob")
12
engineering = Department("Engineering")
13
engineering.add_employee(alice)
14
engineering.add_employee(bob)
15
# Delete the department — Alice and Bob still exist

Deep dive: Aggregation

Composition: “Owns and Controls”

A House has Rooms. Destroy the house, and the rooms are gone. The house controls the lifecycle of its rooms.

1
class House:
2
    def __init__(self, address: str):
3
        self.address = address
4
        # Rooms are created BY the house — they can't exist alone
5
        self.rooms = [
6
            Room("Kitchen"),
7
            Room("Bedroom"),
8
            Room("Bathroom"),
9
        ]
10

11
class Room:
12
    def __init__(self, name: str):
13
        self.name = name

This is the strongest “has-a” relationship and the basis of the Composition over Inheritance principle.

Deep dive: Composition

Dependency: “Temporarily Uses”

A ReportGenerator uses a Printer to print, but doesn’t hold a reference to it. The printer is passed in when needed and then forgotten.

1
class ReportGenerator:
2
    def generate_and_print(self, data: dict, printer: "Printer"):
3
        report = self._format(data)
4
        printer.print(report)  # Uses printer, doesn't own it

This is the weakest relationship—the dependency exists only for the duration of the method call.

Deep dive: Dependency

Inheritance vs Composition: The Debate That Actually Matters

This is the single most important design decision you’ll make in any LLD problem. Get it wrong and your code becomes rigid, fragile, and hard to extend.

When to Use Inheritance

Inheritance is right when there’s a genuine “is-a” relationship and the child class truly represents a specialization of the parent:

1
# ✅ Good: A SavingsAccount IS a BankAccount
2
class BankAccount:
3
    def deposit(self, amount): ...
4
    def withdraw(self, amount): ...
5

6
class SavingsAccount(BankAccount):
7
    def add_interest(self): ...
8

9
# ✅ Good: Each chess piece IS a Piece
10
class Piece:
11
    def can_move(self, board, start, end) -> bool: ...
12

13
class Knight(Piece):
14
    def can_move(self, board, start, end) -> bool:
15
        # L-shaped movement logic
16
        ...

When to Use Composition

Composition is right when classes have a “has-a” relationship, or when you want to combine behaviors flexibly:

1
# ✅ Good: A Car HAS an Engine (not "is an" Engine)
2
class Car:
3
    def __init__(self, engine: Engine, transmission: Transmission):
4
        self.engine = engine
5
        self.transmission = transmission
6

7
# Now we can mix and match:
8
electric_auto = Car(ElectricEngine(), AutomaticTransmission())
9
gas_manual = Car(GasEngine(), ManualTransmission())
10
hybrid_auto = Car(HybridEngine(), AutomaticTransmission())

The Inheritance Trap

Watch what happens when you try to model the same thing with inheritance:

1
# ❌ Bad: Inheritance explosion
2
class ElectricAutomaticCar(Car): ...
3
class ElectricManualCar(Car): ...
4
class GasAutomaticCar(Car): ...
5
class GasManualCar(Car): ...
6
class HybridAutomaticCar(Car): ...
7
class HybridManualCar(Car): ...
8
# 3 engines × 2 transmissions = 6 classes. Add 4WD? Now 12 classes.

With composition, adding a new engine type means one new class. With inheritance, it means N new classes for every combination.

Enums: The Unsung Hero of Clean Design

Enums are criminally underused. Every time you see a string like "active", "pending", or "cancelled" hardcoded in your codebase, that’s a place where an enum would prevent bugs.

1
from enum import Enum
2

3
# ❌ Without enums: typos cause silent bugs
4
def update_order(order_id: int, status: str):
5
    ...
6
update_order(123, "actve")  # Typo — no error, just wrong data
7

8
# ✅ With enums: type safety catches mistakes
9
class OrderStatus(Enum):
10
    PENDING = "pending"
11
    CONFIRMED = "confirmed"
12
    PREPARING = "preparing"
13
    DELIVERED = "delivered"
14
    CANCELLED = "cancelled"
15

16
def update_order(order_id: int, status: OrderStatus):
17
    ...
18
update_order(123, OrderStatus.CONFIRMED)  # ✅ Type-safe
19
update_order(123, OrderStatus.ACTVE)       # ❌ AttributeError — caught immediately

Enums appear in almost every LLD problem: vehicle types in a parking lot, piece types in chess, machine states in a vending machine, order statuses in a restaurant system.

Deep dive: Enums

UML: The Language of LLD Interviews

You don’t need to be a UML expert, but you need to read and draw basic class diagrams. They’re the communication tool of LLD interviews.

Here’s a quick reference for the notation that matters:

The key symbols:

Visibility markers: + public, - private, # protected

In LLD interviews, you’ll draw these on a whiteboard or describe them verbally. Being fluent in this notation shows you think at the design level, not just the code level.

Deep dive: UML Class Diagrams

Interfaces: Contracts That Keep Code Flexible

Interfaces (or abstract base classes in Python) define what a class must do without specifying how. They’re the backbone of extensible design and appear in every well-designed LLD.

1
from abc import ABC, abstractmethod
2

3
class SearchStrategy(ABC):
4
    @abstractmethod
5
    def search(self, catalog: list, query: str) -> list:
6
        pass
7

8
class TitleSearch(SearchStrategy):
9
    def search(self, catalog: list, query: str) -> list:
10
        return [book for book in catalog if query.lower() in book.title.lower()]
11

12
class AuthorSearch(SearchStrategy):
13
    def search(self, catalog: list, query: str) -> list:
14
        return [book for book in catalog if query.lower() in book.author.lower()]
15

16
class ISBNSearch(SearchStrategy):
17
    def search(self, catalog: list, query: str) -> list:
18
        return [book for book in catalog if book.isbn == query]

Why interfaces matter:

1. Testability: Mock the interface in unit tests instead of using the real implementation
2. Extensibility: Add new strategies without modifying existing code (Open/Closed Principle)
3. Decoupling: The caller depends on the interface, not the concrete class (Dependency Inversion)

Deep dive: Interfaces

How OOP Shows Up in LLD Interviews

Let’s connect the theory to practice. Here’s how OOP concepts map to actual interview problems:

Common OOP Interview Questions

Beyond design problems, you might get conceptual OOP questions. Here are the ones that come up most:

Key Takeaways

What to Read Next

• What is Low Level Design? — See how OOP concepts become the building blocks of system design
• Top 20 LLD Interview Questions — Practice applying OOP in real interview problems
• Class Relationships Deep Dive — Master association, aggregation, composition, and dependency
• SOLID Principles — The rules that keep OOP designs clean
• Design Patterns — Reusable solutions built on top of OOP concepts
• LLD Playground — Practice 40+ real problems where OOP skills are the difference maker

OOP is a powerful tool, but like any tool, its value comes from knowing when and how to use it. Master the concepts in this guide, and you’ll have the foundation to design clean systems—not just write classes.