Module 02: OOP Foundations & UML

Why this matters

"Design patterns" is really just a name for recurring, well-tested ways of combining four ideas: encapsulation, abstraction, inheritance, and polymorphism — the "four pillars" of object-oriented design. You already met encapsulation in module 01. This module completes the set, and adds the other half of what every LLD interview actually tests: can you draw your design before you code it? UML (Unified Modeling Language) is the shared notation for that — a class diagram is how you and an interviewer agree on a design's shape in five minutes instead of arguing over fifty lines of code.

Concepts

The four pillars, in one pass

Abstraction: interfaces and abstract classes

Abstraction means defining what operations exist without necessarily saying how they're implemented — a contract, not an implementation. Both languages let you declare a class that can't be instantiated directly, only used as a base that must be completed by a subclass.

from abc import ABC, abstractmethod

class Shape(ABC):              # ABC = Abstract Base Class
    @abstractmethod
    def area(self) -> float:
        ...                    # no implementation — subclasses MUST provide one

class Circle(Shape):
    def __init__(self, radius):
        self.radius = radius

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

# shape = Shape()      # TypeError: Can't instantiate abstract class Shape
circle = Circle(2)
print(circle.area())   # 12.56636

public interface IShape {              // interface: pure contract, no implementation at all
    double Area();
}

public abstract class ShapeBase {      // abstract class: CAN mix real code with abstract members
    public string Name = "shape";
    public abstract double Area();     // subclasses MUST implement this
}

public class Circle : ShapeBase, IShape {
    private double _radius;
    public Circle(double radius) { _radius = radius; }
    public override double Area() {    // 'override' is required — makes the contract explicit
        return Math.PI * _radius * _radius;
    }
}

// var s = new ShapeBase();   // COMPILE ERROR: cannot create an instance of an abstract class
var circle = new Circle(2);
Console.WriteLine(circle.Area());   // 12.566...

Inheritance: reusing and extending a shape

Inheritance models an "is-a" relationship: a Dog is an Animal. The derived (child) class automatically gets everything the base (parent) class defines, and can add new members or override existing ones.

class Animal:
    def __init__(self, name):
        self.name = name

    def make_sound(self):
        return "..."

class Dog(Animal):                    # Dog inherits from Animal
    def make_sound(self):             # OVERRIDING the base method
        return "Woof!"

class Cat(Animal):
    def make_sound(self):
        return "Meow!"

d = Dog("Rex")
print(d.name)          # "Rex" — inherited from Animal, not redefined in Dog
print(d.make_sound())  # "Woof!" — Dog's own version

class Puppy(Dog):
    def __init__(self, name, age_months):
        super().__init__(name)        # runs Animal's __init__ first
        self.age_months = age_months

public class Animal {
    public string Name;
    public Animal(string name) { Name = name; }

    public virtual string MakeSound() {   // 'virtual' = "subclasses MAY override this"
        return "...";
    }
}

public class Dog : Animal {               // Dog inherits from Animal
    public Dog(string name) : base(name) { }   // ': base(name)' calls Animal's constructor

    public override string MakeSound() {       // OVERRIDING — 'override' is mandatory here
        return "Woof!";
    }
}

public class Cat : Animal {
    public Cat(string name) : base(name) { }
    public override string MakeSound() { return "Meow!"; }
}

var d = new Dog("Rex");
Console.WriteLine(d.Name);          // "Rex" — inherited from Animal
Console.WriteLine(d.MakeSound());   // "Woof!" — Dog's own version

Polymorphism: one call, many behaviors

Polymorphism ("many forms") means you can call the same method name on a variable typed as the base/interface, and each actual object responds in its own overridden way — without the calling code needing an if for every possible type.

animals = [Dog("Rex"), Cat("Tom"), Animal("Generic")]

for animal in animals:
    print(f"{animal.name}: {animal.make_sound()}")
# Rex: Woof!
# Tom: Meow!
# Generic: ...

List<Animal> animals = new List<Animal> {
    new Dog("Rex"), new Cat("Tom"), new Animal("Generic")
};

foreach (var animal in animals) {
    Console.WriteLine($"{animal.Name}: {animal.MakeSound()}");
}
// Rex: Woof!
// Tom: Meow!
// Generic: ...

UML class diagrams: drawing a design before coding it

A UML class diagram is a box per class, split into three sections:

┌─────────────────────────┐
│         Animal          │   ← class name
├─────────────────────────┤
│ - name: string           │   ← attributes (fields), with visibility
├─────────────────────────┤
│ + makeSound(): string    │   ← methods, with visibility
└─────────────────────────┘

Visibility symbols prefix every attribute and method:

Relationship lines between boxes are where most of the actual design information lives:

Animal  <|-- Dog              inheritance/generalization (hollow triangle, solid line)
                               "Dog IS-A Animal"

IShape  <|.. Circle            realization/implementation (hollow triangle, DASHED line)
                               "Circle IMPLEMENTS IShape"

Car  o-- Engine                aggregation (hollow diamond)
                               "Car HAS-A Engine, but Engine can outlive the Car"
                               (e.g. swap the engine into a different car)

House  *-- Room                composition (filled diamond)
                               "House OWNS Room; a Room cannot outlive its House"
                               (destroy the House, its Rooms are destroyed with it)

Driver  --> Car                 association (plain arrow)
                               "Driver USES/references a Car" — the weakest relationship

Order  ..> PaymentGateway       dependency (dashed arrow)
                               "Order calls PaymentGateway briefly" — not a stored reference,
                               just "this class depends on that one to do its job"

Aggregation vs. composition is the one distinction interviewers actually probe, because it changes your code's lifetime management: if deleting the container should also delete its parts, that's composition (the parts are typically created inside the container's constructor and never shared outside it); if the parts have independent existence, that's aggregation (they're typically passed in from outside).

Multiplicity (how many of one class relate to how many of another) is written at each end of a line: Driver "1" --> "0..*" Car means one Driver can be associated with zero or more Cars.

UML sequence diagrams: showing a flow over time

Where a class diagram shows structure (what exists), a sequence diagram shows behavior over time (what calls what, in order) — essential for explaining a use case like "what happens when a user places an order."

Customer          Order              PaymentGateway         Inventory
   |                 |                      |                    |
   |--placeOrder()-->|                      |                    |
   |                 |----charge()--------->|                    |
   |                 |                      |--(success)-------->|
   |                 |<---(charged)---------|                    |
   |                 |------------reserveItems()--------------->|
   |                 |<-----------------(reserved)---------------|
   |<--(confirmed)---|                      |                    |
   |                 |                      |                    |

Each vertical line is a lifeline (one object/participant). Each horizontal arrow is a message (a method call), read top to bottom in the order things actually happen. You'll draw diagrams exactly like this one, by hand, in module 11 (turning requirements into diagrams) and again in every classic-problem module from 12 onward — this is the actual whiteboard skill an LLD interview tests.

Hands-on exercises

1. Build the Animal hierarchy

Implement the Animal/Dog/Cat hierarchy from the Inheritance section above, in both languages, plus one more subclass, Bird, that overrides make_sound/MakeSound to return "Tweet!". Put all four in one collection and loop over it printing each sound (the Polymorphism example) — confirm you see all four distinct outputs from one loop with one method call.

2. Add an abstract method

Make Animal/ShapeBase-style abstraction real: turn make_sound into an abstract method (Python: @abstractmethod on an ABC; C#: abstract on an abstract class) so that Animal itself can no longer be instantiated directly, only its subclasses. Confirm attempting to instantiate the base class now fails.

3. Draw it first

Before writing any code, draw (as text/ASCII, like the examples above) a UML class diagram for a Library that has many Books (composition — books are created by and belong to the library) and lends to many Members (association — members exist independently of the library). Include visibility symbols and at least one method on each class. Then implement it in both languages and check your code actually matches what you drew.

4. Sequence diagram for a real flow

Draw a sequence diagram (text/ASCII) for "a Member borrows a Book from a Library" using the classes from exercise 3 — at minimum it should show the Member calling something on Library, Library checking the Book's availability, and a final confirmation back to Member.

Independent challenge

No code given.

Task: Design and implement a small Shape hierarchy, in both languages: an abstract Shape with abstract area() and perimeter() methods, and at least three concrete subclasses (Circle, Rectangle, Triangle). Then write a function that takes a collection of Shapes (typed as the abstract base — this is the polymorphism part) and returns the total area of all of them, without any if/isinstance/type -checking inside that function. Draw the UML class diagram for this hierarchy first, before writing the code, exactly as you practiced in exercise 3.

Common mistakes & troubleshooting

• Forgetting virtual/override in C#. If a base method isn't marked virtual (or abstract), a subclass's same-named method doesn't override it — it silently hides it instead, and which version runs depends on the declared type of the variable, not the actual object, which is almost never what you want and is a genuine, common bug source.
• Forgetting to call the base constructor. In C#, if the base class has no parameterless constructor, you must call : base(...) explicitly with matching arguments, or it won't compile. In Python, forgetting super().__init__(...) compiles fine but silently skips the parent's setup — a much sneakier bug because Python won't stop you.
• Reaching for inheritance when you mean "has-a." Just because two classes share some behavior doesn't mean one should inherit from the other — inheritance should model "is-a," not "reuses some code from." (Module 05 covers this in depth: composition-over-inheritance.)
• Confusing interface and abstract class in C#. Interface: pure contract, no fields, a class can implement many. Abstract class: can mix real code with abstract requirements, a class can inherit from only one. If you need "shared code across several unrelated types," that's usually an interface each implements independently, not a forced shared abstract base.
• Drawing composition when you mean aggregation (or vice versa). Ask yourself: "if I delete the container, should the parts also die?" Yes → composition (filled diamond). No, they can be reused/reassigned elsewhere → aggregation (hollow diamond). Getting this wrong in an interview signals you haven't thought about object lifetime.

Checkpoint quiz

1. Name the four pillars of OOP and give a one-sentence definition of each.
2. In C#, what two keywords are both required to make method overriding work correctly, and where does each go?
3. What's the practical difference between an interface and an abstract class in C#? Does Python distinguish them the same way?
4. In the polymorphic "total area" example, why is it wrong for the total-area function to contain if isinstance(shape, Circle): ...?
5. What UML diamond (hollow or filled) represents composition, and what does that imply about object lifetime?
6. What's the difference between association and dependency in UML?

Interview questions

1. "Explain the four pillars of OOP with a real example, not just definitions." Encapsulation: a BankAccount's balance is private, only changed via deposit/withdraw. Abstraction: callers of Shape.area() don't need to know how each shape computes it. Inheritance: SavingsAccount and CheckingAccount both extend a shared Account base. Polymorphism: a loop over List<Account> calling .calculateInterest() runs each account type's own logic without an if chain.
2. "What's the difference between method overriding and method overloading?" Overriding: a subclass replaces a base class's method with its own implementation (same name, same signature, runtime dispatch based on actual object type). Overloading: multiple methods with the same name but different parameter signatures in the same class, resolved at compile time based on the arguments passed — a different mechanism entirely (you saw this with C# constructor overloads in module 01).
3. "When would you choose an abstract class over an interface, or vice versa?" Interface, when unrelated types need to promise the same capability with no shared implementation (a Flyable interface implemented by both Bird and Airplane, which share nothing else). Abstract class, when subclasses genuinely share a common "is-a" lineage and some real reusable implementation, not just a shared method signature.
4. "What is duck typing, and does C# support it?" Duck typing (from Python's world): if an object has the method you're about to call, you can call it, regardless of its declared type or inheritance — "if it quacks like a duck." C# is statically typed and requires a shared type (interface, base class, or dynamic, rarely used) to call a method polymorphically — it doesn't support duck typing the way Python does by default.
5. "What's the difference between aggregation and composition, and why does it matter in a design?" Both are "has-a" relationships; the difference is lifetime ownership. Composition: the part cannot exist independently of the whole (a Room inside a House) — when the whole is destroyed, so are its parts. Aggregation: the part has an independent lifetime and can be shared or reassigned (an Engine that could be moved to a different Car). It matters because it drives real decisions: who constructs the part, who's responsible for cleaning it up, and whether it can be shared.

Cumulative review

Closed-book. Pulls from modules 00–02.

1. (00 + 01) What does self/this refer to inside an instance method, and how is it made explicit differently in Python vs. C#?
2. (00 + 02) 7 / 3 truncates to 2 in C#. Given that C# is statically typed, why does the compiler allow this instead of refusing to compile it?
3. (01 + 02) A property with a validating setter, and an abstract method, are both a form of the same OOP pillar. Which one, and why?
4. (01 + 02) Why does forgetting super().__init__()/: base(...) (module 01/02) tend to produce a much sneakier bug in Python than in C#?
5. (02) In the Animal/Dog/Cat polymorphism example, what would happen if Dog didn't override make_sound/MakeSound at all?

Further reading & sources

• Python: abc — Abstract Base Classes - official reference for ABC/@abstractmethod.
• Microsoft Learn: Inheritance (C#) - virtual/override/base in depth.
• Microsoft Learn: Interfaces (C#) - official interface reference, including multiple-implementation.
• UML class diagram relationships (association, aggregation, composition, generalization) - the authoritative visual notation reference this module's ASCII diagrams are based on.
• UML sequence diagrams reference - lifelines, messages, activation bars in full notation.

Next

03-generics-exceptions-and-value-objects — generic/type-safe classes and methods, designing an exception hierarchy instead of throwing generic errors everywhere, and modeling immutable value objects with enums and records/dataclasses.