OOP Fundamentals & Class Relationships

Course roadmap (short) ▶ 0:22:00 – 0:50:14

The LLD track moves from fundamentals to design patterns and then to solving real design problems.

LLD track, in order

1. OOP fundamentals: class/object and the 4 pillars. Polymorphism matters most.
2. Relationships & UML: association, aggregation and composition.
3. SOLID principles, with small project assignments.
4. Design patterns: creational, then structural, then behavioral, with live code and which pattern fits which problem.
5. Problem practice ("the grind"): about 15–20 standard problems, such as a notification system, ATM, vending machine, parking lot, Splitwise, rate limiter and search/filter system. Solve each in 45–60 minutes with a timer.
6. Mock interviews, in pairs.

Setup: keep one Git repo with an lld/ folder, and push everything you practise. Notes and recordings go on Google Classroom.

Why OOP? Class vs object ▶ 1:01:02 – 1:29:16

A class is a blueprint that defines state (data) and behavior (methods). An object is one real instance of that blueprint, with memory and its own state.

The problem

Say you have 5 users. Each has their own data, and some functions must act on that user's data. You can do this in C with a struct and functions that take the struct as an argument. It gets painful as the system grows, though. C also has no private, so any code can change any field, and nothing enforces the rules.

Real-world problems have replication (thousands of users, cars and orders, all the same shape with different data), hierarchy, data hiding and varying behavior. OOP is an idea that models these directly. A language that supports the 4 pillars (encapsulation, abstraction, inheritance and polymorphism) is called an OOP language.

Methods are the controllers of state

You don't reach inside a car and change the fuel level yourself. You call start() or accelerate(), and those methods change several fields in a controlled way. How do you know an object has "changed"? Its field values are different from before. Methods are the doors through which the outside world asks an object to change.

class Car:
    """The blueprint. No car exists until we create one."""

    def __init__(self, model: str, fuel_litres: float) -> None:
        # state (data) of ONE car
        self.model = model
        self.fuel_litres = fuel_litres
        self.speed_kmph = 0
        self.odometer_km = 0.0
        self.running = False

    # behavior = controllers of the state
    def start(self) -> None:
        self.running = True

    def accelerate(self, delta: int) -> None:
        if not self.running:
            raise RuntimeError("Start the car first")
        self.speed_kmph += delta

    def drive(self, km: float) -> None:
        self.odometer_km += km
        self.fuel_litres -= km / 15        # about 15 km per litre


# usage: two objects from one blueprint
car1 = Car("Swift", fuel_litres=40)
car2 = Car("Swift", fuel_litres=40)        # identical "out of the showroom"

car1.start(); car1.accelerate(60); car1.drive(300)
print(car1.odometer_km, round(car1.fuel_litres, 1))   # 300.0 20.0
print(car2.odometer_km, car2.fuel_litres)             # 0.0 40   (own state, untouched)

When do you need a class, and when not?

• Make a class when data and the functions that work on it are inter-related, and you need many instances, each with its own state.
• No class needed for stateless computation. add(25, 30) or sqrt(5) doesn't care who calls it or keep any memory, so it belongs in a utility module.
• If you need exactly one instance (logger, JSON parser, config), that is the Singleton pattern, covered later.
• A method that never touches the object's state is a "dummy" method from an OOP point of view. It probably belongs elsewhere.

# Stateless helper: a plain module-level function is fine in Python
def add(a: int, b: int) -> int:
    return a + b

print(add(25, 30))   # 55

Encapsulation ▶ 1:29:16 – 1:43:48

Bundle data with the methods that use it, and let the outside world change that data only through controlled methods. The core idea is control and privacy.

The problem

If age is a public field, any client code can write user.age = -5, and nothing stops it. Now picture 1,000 places in the codebase that assign age directly. When a bad value appears, you have to check all 1,000.

The litmus test

Ask whether client code (outside the class) can read or change a field directly, bypassing validation. If it can, encapsulation is violated. "The language allows it" is no defence. Defend the OOP principle, not the language.

Building it step by step

Bad version: public fields, no checks.

class User:
    def __init__(self, name: str, age: int) -> None:
        self.name = name
        self.age = age

u = User("Asha", 30)
u.age = -5            # nobody validates this, so the object is now invalid
print(u.age)          # -5

Encapsulated version: internal fields plus @property, so every write goes through one validation point.

class User:
    def __init__(self, name: str, age: int) -> None:
        self._name = name     # leading _ means "internal, don't touch from outside"
        self.age = age        # goes through the setter below, so it is validated at creation too

    @property
    def name(self) -> str:    # read-only: there is no setter
        return self._name

    @property
    def age(self) -> int:
        return self._age

    @age.setter
    def age(self, value: int) -> None:
        # the ONE place that guards this field (centralised validation)
        if not 0 <= value <= 150:
            raise ValueError(f"invalid age: {value}")
        self._age = value


# usage
u = User("Asha", 30)
u.age = 31                 # looks like a field, but runs the setter
print(u.name, u.age)       # Asha 31
try:
    u.age = -5
except ValueError as e:
    print(e)               # invalid age: -5
try:
    u.name = "Hacker"
except AttributeError as e:
    print("name is read-only")   # name is read-only

Python's "private": _name and __name

Python has no real private keyword. It relies on two conventions:

• _name (one underscore) is a convention meaning "internal, please don't use from outside". Nothing enforces it, but linters and IDEs warn about it.
• __name (two underscores) triggers name mangling. Inside class Account, Python renames __salary to _Account__salary. The main purpose is to stop a subclass from accidentally overwriting the parent's attribute. It is not a security feature.

class Account:
    def __init__(self, salary: int) -> None:
        self.__salary = salary          # stored as _Account__salary

    def salary_band(self) -> str:       # controlled behavior: expose a band, not the number
        return "high" if self.__salary > 100_000 else "normal"

a = Account(120_000)
print(a.salary_band())                  # high
try:
    print(a.__salary)
except AttributeError:
    print("no attribute __salary")      # no attribute __salary
print(a._Account__salary)               # 120000  (still reachable, so this is NOT security)

Why it matters

• It prevents direct, invalid or inconsistent changes to state.
• Centralised validation: when debugging a bad speed, you check one setter instead of 1,000 call sites.
• The code is easier to maintain, safer and more predictable.

Abstraction ▶ 2:07:00 – 2:12:40

Expose what an object does and hide how it does it. You achieve it with interfaces or abstract classes.

The problem

If client code knows the internal details (which data structure, which SMS provider), every change inside forces changes in every client. The two sides are tightly coupled.

The idea in one line

Define a contract (method names + meaning). Any implementation that honours the contract can be plugged in without changing the client. Use it whenever there are, or may later be, several ways to do the same job.

Classic example: Stack is an Abstract Data Type

Is a stack an array or a linked list? Neither. A stack is defined only by its operations and what they mean: push, pop, top and size. You can implement it with an array or a linked list, and the client can't tell the difference.

from abc import ABC, abstractmethod
from dataclasses import dataclass
from typing import Any, Optional


class Stack(ABC):
    """The contract: WHAT a stack does. No HOW."""
    @abstractmethod
    def push(self, item: Any) -> None: ...
    @abstractmethod
    def pop(self) -> Any: ...
    @abstractmethod
    def top(self) -> Any: ...
    @abstractmethod
    def size(self) -> int: ...


class ArrayStack(Stack):
    """HOW #1: contiguous memory (a Python list)."""
    def __init__(self) -> None:
        self._items: list[Any] = []
    def push(self, item: Any) -> None: self._items.append(item)
    def pop(self) -> Any: return self._items.pop()
    def top(self) -> Any: return self._items[-1]
    def size(self) -> int: return len(self._items)


@dataclass
class _Node:
    value: Any
    next: Optional["_Node"] = None


class LinkedListStack(Stack):
    """HOW #2: non-contiguous memory (nodes linked by references)."""
    def __init__(self) -> None:
        self._head: Optional[_Node] = None
        self._count = 0
    def push(self, item: Any) -> None:
        self._head = _Node(item, self._head)
        self._count += 1
    def pop(self) -> Any:
        node = self._head
        self._head = node.next
        self._count -= 1
        return node.value
    def top(self) -> Any: return self._head.value
    def size(self) -> int: return self._count


def reverse(word: str, stack: Stack) -> str:
    """Client code: depends only on the contract."""
    for ch in word:
        stack.push(ch)
    return "".join(stack.pop() for _ in range(stack.size()))


# usage
print(reverse("design", ArrayStack()))       # ngised
print(reverse("design", LinkedListStack()))  # ngised
# Stack()  -> TypeError: Can't instantiate abstract class Stack

classDiagram
  class Stack {
    +push(item)
    +pop()
    +top()
    +size()
  }
  class ArrayStack
  class LinkedListStack
  ArrayStack ..|> Stack
  LinkedListStack ..|> Stack

Side note: array vs linked list memory

• Array = one contiguous block. Element i is at base_address + i × size_of_type. That formula doesn't depend on the array's length, so random access is O(1).
• Linked list = scattered nodes, each holding a reference to the next. There is no formula, so you must walk the chain, which is O(n).

Inheritance ▶ 1:43:48 – 2:07:00

A child class reuses the parent's properties and behavior, adds its own, and can override what it wants to do differently. It models an IS-A relationship.

The problem

Without inheritance, every new class rebuilds from scratch what similar classes already have, and the same logic is copied in many places.

Vocabulary

• Parent = superclass or base class. Child = subclass or derived class.
• IS-A: "Dog is an Animal" and "SmsNotification is a Notification". If the IS-A sentence sounds wrong in the real world, don't inherit. Code will happily let you write Robot(Animal), but it is a bad model. The Liskov Substitution Principle (in SOLID) makes this rule formal.
• Declaration = signature only: def add(a, b). Definition = signature plus body.

Real inheritance vs "forced inheritance"

An abstract class mixes both. Some methods have a definition you want reused, and others are abstract and must be implemented. Rule of thumb: put non-negotiable shared behavior (every animal breathes) in an abstract base class. Put optional capabilities (flying) in an interface.

from abc import ABC, abstractmethod


class Animal(ABC):
    def __init__(self, name: str) -> None:
        self.name = name

    def breathe(self) -> str:                  # gift: shared logic, reused as-is
        return f"{self.name} breathes"

    @abstractmethod
    def make_sound(self) -> str:               # expectation: each child must define it
        ...


class Flyable(ABC):                            # optional capability = "interface"
    @abstractmethod
    def fly(self) -> str: ...


class Dog(Animal):
    def make_sound(self) -> str:
        return "Woof"


class Bird(Animal, Flyable):                   # IS-A Animal, and CAN fly
    def __init__(self, name: str, wingspan_cm: int) -> None:
        super().__init__(name)                 # set up the parent part first
        self.wingspan_cm = wingspan_cm

    def make_sound(self) -> str:
        return "Tweet"

    def fly(self) -> str:
        return f"{self.name} flies with a {self.wingspan_cm} cm wingspan"


# usage
d, b = Dog("Bruno"), Bird("Kiwi", 20)
print(d.breathe(), "|", d.make_sound())   # Bruno breathes | Woof
print(b.breathe(), "|", b.fly())          # Kiwi breathes | Kiwi flies with a 20 cm wingspan

classDiagram
  class Animal {
    +name
    +breathe()
    +make_sound()
  }
  class Flyable {
    +fly()
  }
  class Dog {
    +make_sound()
  }
  class Bird {
    +wingspan_cm
    +make_sound()
    +fly()
  }
  Dog --|> Animal
  Bird --|> Animal
  Bird ..|> Flyable

"Why inherit if I can just hold a parent object?"

A student asked this. If class C keeps an A() inside, it can call all of A's methods. What does inheritance add? Two things. First, customisation: the child can keep methods 1–4 and override method 5. Second, substitutability: a child can be used anywhere an A is expected, and that is what polymorphism is built on.

class A:
    def m4(self) -> str: return "A.m4"
    def m5(self) -> str: return "A.m5"
    def run(self) -> str: return f"{self.m4()} + {self.m5()}"


class B(A):                     # IS-A: reuse m4, override only m5
    def m5(self) -> str: return "B.m5 (custom)"


class C:                        # HAS-A: holds an A, can call it, can't change it
    def __init__(self) -> None:
        self.a = A()
    def run(self) -> str: return self.a.run()


print(B().run())   # A.m4 + B.m5 (custom)   (A's run() picks up B's override)
print(C().run())   # A.m4 + A.m5            (no way to customise m5 from outside)

Polymorphism ▶ 2:12:40 – 2:33:00

"One interface, many implementations": the same method call does different things depending on the actual object. The teacher called this the most important pillar for LLD, because most design patterns are built on it.

The problem

Without it, the client needs an if/elif chain such as "if SMS do this, if email do that, if push do the other". The chain grows every time a new channel is added, and it gets copied into every caller.

Two kinds

Python has no method overloading, so use default arguments

In Python, a second def area(...) in the same class simply replaces the first. To get "one name, different parameter lists", use default or optional arguments. The class example was "pass a radius for a circle, or length and breadth for a rectangle".

import math


class Shape:
    def area(self, a: float, b: float | None = None) -> float:
        if b is None:                 # one argument: treat as circle radius
            return math.pi * a * a
        return a * b                  # two arguments: rectangle length x breadth


s = Shape()
print(round(s.area(2), 2))   # 12.57
print(s.area(3, 4))          # 12

The key rule: reference type vs object type

In Java, A a2 = new B(); is allowed because a B IS-A A. Two rules follow:

1. The reference type (left side) decides what you can call. a2.m1() fails to compile with "method m1 is undefined for type A". A parent knows nothing about methods a child added later. A 1950 car has no idea about 2025 features.
2. The object type (right side) decides which implementation runs for overridden methods. a2.send() runs B's send. That is runtime polymorphism. If B doesn't override, the parent's version runs.

class A:
    def m5(self) -> str: return "A.m5"
    def send(self) -> str: return "A.send"


class B(A):
    def m1(self) -> str: return "B.m1"           # new method, unknown to A
    def send(self) -> str: return "B.send"       # override


a1: A = A()
a2: A = B()            # allowed: a B IS-A A
b: B = B()

print(a1.send())       # A.send
print(a2.send())       # B.send   (the actual object decides)
print(a2.m5())         # A.m5     (not overridden, so the parent's version runs)
print(b.m1(), b.m5())  # B.m1 A.m5
# a2.m1()  -> a type checker (mypy) reports: "A" has no attribute "m1"

The notification example, step by step

Bad version: the client branches on the type.

def notify(pref: str, msg: str) -> None:
    if pref == "sms":
        print(f"SMS: {msg}")
    elif pref == "email":
        print(f"Email: {msg}")
    # every new channel means editing this function, and every copy of it

Improved version: the client depends on the Notification abstraction, and the call is routed at runtime.

from abc import ABC, abstractmethod


class Notification(ABC):
    @abstractmethod
    def send(self, message: str) -> None: ...


class SmsNotification(Notification):
    def send(self, message: str) -> None:
        print(f"SMS  -> {message}")


class EmailNotification(Notification):
    def send(self, message: str) -> None:
        print(f"Email-> {message}")


class PushNotification(Notification):
    def send(self, message: str) -> None:
        print(f"Push -> {message}")


def get_notification(user_pref: str) -> Notification:
    channels = {"sms": SmsNotification, "email": EmailNotification, "push": PushNotification}
    return channels[user_pref]()


# usage: the client writes ONE statement; the object decides the behavior
for pref in ("sms", "email", "push"):
    n: Notification = get_notification(pref)
    n.send("Your order has shipped")
# SMS  -> Your order has shipped
# Email-> Your order has shipped
# Push -> Your order has shipped

classDiagram
  class Client
  class Notification {
    +send(message)
  }
  class SmsNotification {
    +send(message)
  }
  class EmailNotification {
    +send(message)
  }
  class PushNotification {
    +send(message)
  }
  Client --> Notification : uses
  SmsNotification --|> Notification
  EmailNotification --|> Notification
  PushNotification --|> Notification

Class relationships: association, aggregation, composition ▶ 2:47:28 – 3:31:16

The relationship tells you how strongly two classes depend on each other. Association means they use each other. Aggregation means one has (collects) the other. Composition means one owns the other, and the part lives and dies with it.

The problem

Real systems are full of collaborating objects. Amazon has users, orders, payments, carts, inventory, catalogs and recommendations. Naming how they relate makes a design readable. It also tells you which objects depend on which, and what must be cleaned up before what. Not every pair is related: an order service and a payment service may not know each other at all. Only draw a relationship you can justify with a meaningful verb ("doctor treats patient"; "doctor ... engineer"? There's no verb, so there's no line).

Association   (weakest, most general: "uses / knows about")
  └── Aggregation   ("has-a": collects references, independent lifecycles)
        └── Composition   (strongest: "owns", lifecycle-dependent)

Every aggregation and composition is also an association. Inheritance (IS-A) is a separate kind of relationship.

1. Association: "uses / knows about"

class Patient:
    def __init__(self, name: str) -> None:
        self.name = name


class Doctor:
    def __init__(self, name: str) -> None:
        self.name = name

    def treat(self, patient: Patient) -> str:   # uses a Patient; keeps no list, creates nothing
        return f"Dr. {self.name} treats {patient.name}"


print(Doctor("Rao").treat(Patient("Meera")))   # Dr. Rao treats Meera

2. Aggregation: "has-a" (a collection of independent objects)

class Player:
    def __init__(self, name: str) -> None:
        self.name = name


class Team:
    def __init__(self, name: str) -> None:
        self.name = name
        self._players: list[Player] = []          # stores REFERENCES

    def add_player(self, player: Player) -> None:  # player is created OUTSIDE and passed in
        self._players.append(player)

    def roster(self) -> list[str]:
        return [p.name for p in self._players]


# usage
p1, p2 = Player("Virat"), Player("Rohit")   # they exist before any team
team = Team("Blue")
team.add_player(p1)
team.add_player(p2)
print(team.roster())    # ['Virat', 'Rohit']

del team                # the team is gone...
print(p1.name)          # Virat   (...the players live on)

3. Composition: "owns" (strongest)

import weakref


class Room:
    def __init__(self, name: str) -> None:
        self.name = name


class House:
    def __init__(self) -> None:
        # the House CREATES its rooms; nobody outside made them, so it owns them
        self._rooms = [Room("Kitchen"), Room("Bedroom")]

    def room_names(self) -> list[str]:
        return [r.name for r in self._rooms]


# usage
house = House()
print(house.room_names())                 # ['Kitchen', 'Bedroom']

kitchen = weakref.ref(house._rooms[0])    # peek only; a weak ref doesn't keep it alive
del house                                 # destroy the owner...
print(kitchen())                          # None   (...its rooms are gone too, in CPython)

classDiagram
  class Doctor {
    +treat(patient)
  }
  class Patient
  class Team {
    +add_player(player)
    +roster()
  }
  class Player
  class House {
    +room_names()
  }
  class Room
  Doctor --> Patient : treats
  Team o-- Player : has
  House *-- Room : owns

Quick identification test

1. Does A create B, so that B can't outlive A? → Composition (filled diamond ◆ on A's side).
2. Does A keep a collection or reference of Bs that exist independently? → Aggregation (hollow diamond ◇ on A's side).
3. Do they only interact or know about each other? → Association (plain line or arrow, labelled with the verb).
4. Does "B is an A" make sense? → Inheritance (generalisation). Implementing an interface is realisation.

Homework: read up on the OOP pillars, the three relationships and static variables. Code A/B overriding, Team/Player and House/Room yourself. Next class is SOLID.

UML class diagram cheat sheet ▶ 1:48:20 – 1:50:10 · 3:21:09 – 3:25:53

UML (Unified Modeling Language) is how you sketch classes and their relationships before writing code. Any picture of classes plus relationships drawn without code counts.

A class box

┌──────────────────┐
│    ClassName     │   name
├──────────────────┤
│ - private_field  │   fields (state)
│ + public_field   │
├──────────────────┤
│ + public_method()│   methods (behavior)
│ - helper()       │
└──────────────────┘

classDiagram
  class Animal
  class Dog
  class Flyable
  class Bird
  class Employee
  class Company
  class Team
  class Player
  class Order
  class OrderItem
  Dog --|> Animal : is a
  Bird ..|> Flyable : implements
  Employee --> Company : works in
  Team o-- Player : has
  Order *-- OrderItem : consists of