OO Fundamentals & UML

Before any pattern or principle makes sense, you need a solid grip on four ideas — abstraction, encapsulation, inheritance, polymorphism — and on how objects relate to each other in code (association, aggregation, composition, delegation). This chapter also gives you UML, the diagramming language you'll use throughout the module to draw designs before you build them. Everything here is the vocabulary the rest of the course assumes you already have.

The four pillars of OOP

Object-oriented programming rests on four ideas. They aren't independent — encapsulation makes abstraction trustworthy, inheritance is one way to reuse abstractions, and polymorphism is what makes inheritance (and interfaces) actually pay off at runtime. Learn them together.

Abstraction

Abstraction is a simplified model of something real, kept only as detailed as your context needs. When you turn a real-world "airplane" into a class, you don't try to capture every bolt and wire — you capture only the attributes and behaviours that matter for the program you're writing, and you throw the rest away on purpose.

A subtlety from the slides that's easy to miss: the same real-world thing gets different abstractions depending on why you're modelling it. An Airplane class in a flight simulator and an Airplane class in a booking system share a name — and nothing else.

public class Airplane
{
    public double AltitudeMeters { get; private set; }
    public double SpeedKnots { get; private set; }
    public double FuelKg { get; private set; }

    public void ApplyThrust(double percent)
    {
        // physics: accelerate, burn fuel, climb...
        FuelKg -= percent * 0.4;
        SpeedKnots += percent * 2.1;
    }
}

public class Airplane
{
    public string TailNumber { get; }
    public SeatMap Seats { get; } = new();

    public Airplane(string tailNumber) => TailNumber = tailNumber;

    public bool TryReserveSeat(string seatCode) =>
        Seats.Reserve(seatCode);
}

Neither version is "more correct." Each is the right abstraction for its purpose — a lesson that generalises: whenever you design a class, ask "what does this program actually need to know about this thing?" before you write a single field.

Encapsulation

Encapsulation means hiding an object's internal state and exposing only the operations that are safe to call from outside. A class is a template — encapsulation is the promise that template makes: "you can only change my state through my methods, so I can guarantee I never end up in a nonsense state."

Watch what happens without it — a BankAccount with a public field has no way to reject an invalid value, because there's no code path to reject it through:

var acc = new BankAccount();
acc.Balance = -500; // perfectly legal, and now the account is broken

public class BankAccount
{
    public decimal Balance;
}

public class BankAccount
{
    private decimal _balance;

    public decimal Balance
    {
        get => _balance;
        private set
        {
            if (value < 0)
                throw new ArgumentException("Balance cannot be negative.");
            _balance = value;
        }
    }

    public BankAccount(decimal openingBalance) => Balance = openingBalance;

    public void Deposit(decimal amount)
    {
        if (amount <= 0) throw new ArgumentException("Deposit must be positive.");
        Balance += amount;
    }

    public void Withdraw(decimal amount)
    {
        // The guard below is part of the invariant too: without it, Withdraw(-100)
        // would INCREASE the balance — the exact bug encapsulation exists to prevent.
        if (amount <= 0) throw new ArgumentException("Withdrawal amount must be positive.");
        if (amount > Balance) throw new InvalidOperationException("Insufficient funds.");
        Balance -= amount;
    }
}

The slides put it simply: attributes are usually private, and only methods of the same class can touch them; protected extends that trust to subclasses too.

Inheritance

Inheritance lets you build a new class on top of an existing one, reusing its fields and methods instead of duplicating them. The new class (subclass / derived class) extends the existing one (superclass / base class), and can override inherited behaviour — replacing it entirely, or calling the base version and adding to it.

Compare writing two unrelated classes against extending one:

public class Employee
{
    public string Name { get; }
    public decimal MonthlySalary { get; }
    public Employee(string name, decimal salary)
        { Name = name; MonthlySalary = salary; }
    public decimal GetAnnualSalary() => MonthlySalary * 12;
}

public class Manager
{
    public string Name { get; }              // duplicated
    public decimal MonthlySalary { get; }     // duplicated
    public decimal Bonus { get; }
    public Manager(string name, decimal salary, decimal bonus)
        { Name = name; MonthlySalary = salary; Bonus = bonus; }
    public decimal GetAnnualSalary() => MonthlySalary * 12 + Bonus; // duplicated formula
}

public class Employee
{
    public string Name { get; }
    public decimal MonthlySalary { get; }

    public Employee(string name, decimal salary)
    {
        Name = name;
        MonthlySalary = salary;
    }

    public virtual decimal GetAnnualSalary() => MonthlySalary * 12;
}

public class Manager : Employee
{
    public decimal AnnualBonus { get; }

    public Manager(string name, decimal salary, decimal bonus)
        : base(name, salary) => AnnualBonus = bonus;

    // Overriding: enhances the base behaviour rather than replacing it
    public override decimal GetAnnualSalary() =>
        base.GetAnnualSalary() + AnnualBonus;
}

Polymorphism

Polymorphism means code can call an operation on an object without knowing its exact type — and the object's own, specific implementation runs anyway. "Poly-morph" literally means "many forms": a Shape reference might, at runtime, actually point to a Circle or a Square, and calling shape.Area() runs whichever one is really there.

This is only possible because C# supports abstract classes (a base class that can declare a method with no implementation, forcing every subclass to supply one) together with virtual/override (the base marks a method overridable; subclasses opt in to replacing it).

// The client only knows about Shape — never Circle or Square by name.
List<Shape> shapes = new()
{
    new Circle { Radius = 2 },
    new Square { Side = 3 },
};

double total = 0;
foreach (Shape s in shapes)
    total += s.Area();   // runs Circle's Area() or Square's Area() — decided at RUNTIME

Console.WriteLine($"Total area: {total:F2}");

public abstract class Shape
{
    // No implementation here — every concrete shape MUST provide one.
    public abstract double Area();
}

public class Circle : Shape
{
    public double Radius { get; init; }
    public override double Area() => Math.PI * Radius * Radius;
}

public class Square : Shape
{
    public double Side { get; init; }
    public override double Area() => Side * Side;
}

The slides call the runtime lookup of "which method body actually runs" dynamic binding, and note it's what makes objects with the same interface substitutable for each other — which is exactly polymorphism. This leads to one of the most quoted lines in OO design:

Overloading vs. overriding

These two terms sound alike and get mixed up constantly — but they're unrelated mechanisms.

// The COMPILER picks which one to call, based on argument types —
// resolved before the program ever runs.
var calc = new Calculator();
calc.Add(1, 2);       // calls Add(int,int)
calc.Add(1.0, 2.0, 3.0); // calls Add(double,double,double)

public class Calculator
{
    public double Add(double a, double b) => a + b;
    public double Add(double a, double b, double c) => a + b + c;
    public int Add(int a, int b) => a + b;
}

// The RUNTIME type of the object decides which Area() runs —
// resolved while the program is executing.
Shape s = new Circle { Radius = 2 };
s.Area(); // runs Circle's version, even though 's' is typed as Shape

public class Shape
{
    public virtual double Area() => 0;
}

public class Circle : Shape
{
    public double Radius { get; init; }
    public override double Area() => Math.PI * Radius * Radius;
}

OO analysis, design & implementation

Building an OO system isn't one step — the slides break it into three:

Finding appropriate objects

There's no single recipe, and the slides are candid that experts disagree:

• Noun/verb parsing — write a problem statement in plain English, underline the nouns (candidate classes) and verbs (candidate methods).
• Responsibility-driven design — focus on what collaborations and responsibilities the system needs, and let classes fall out of that.
• Real-world modelling — translate the objects you find during analysis directly into design classes.

Specifying object interfaces

Every operation a class exposes has a signature — its name, its parameter types, and its return type. The complete set of signatures a class exposes is its interface: the full menu of requests you're allowed to send that object.

Matching a request to the actual code that runs, at runtime, is dynamic binding — the same idea you just saw as polymorphism. It's why interfaces matter so much in good design: a client that only knows IShape can be handed any class that implements it, without caring which one, or even knowing it changed. That's the essence of Dependency Inversion and Interface Segregation, covered fully in Chapter 2.

Class relationships

Objects rarely work alone — the interesting design decisions are usually about how two classes relate. The slides give four relationships, and the important nuance is that aggregation and composition are both special cases of association, distinguished only by ownership of lifetime.

The whole spectrum in one running example, adapted from the Hospital/Department exercise: a Hospital owns its Departments (composition) — close the hospital and its departments are gone. A Department merely uses a Doctor (aggregation) — close the department and the doctor is still a doctor, just unemployed. And a Doctor and a Patient just interact for the duration of one call (dependency, the weakest relationship of all — see above) — neither owns, nor even stores a reference to, the other.

Association

Association is a "using" relationship between two independent objects — neither owns the other, and both keep their own lifetime. The slides' example: a doctor can see many patients, a patient can see many doctors, and deleting either one has zero effect on the other.

One more distinction worth making precisely: if the other object is only ever received as a method parameter or local variable — never stored anywhere — that's technically the even weaker dependency relationship (formalised in the UML section below). The code below is exactly that case: Doctor never stores the Patient it's handed. Genuine association usually means one object holds a reference to another (a field), even without owning its lifetime — which is what makes aggregation and composition (both held references) special cases of it.

public class Doctor
{
    public string Name { get; }
    public string Specialty { get; }

    public Doctor(string name, string specialty)
    {
        Name = name;
        Specialty = specialty;
    }

    // DEPENDENCY: Patient is just a parameter for the duration of this call.
    // Doctor doesn't store it, doesn't own it, doesn't outlive or control it.
    // (This is the weakest using-relationship — see the note above.)
    public Prescription WritePrescription(Patient patient, string medication)
    {
        Console.WriteLine($"{Name} is writing a prescription for {patient.Name}...");
        return new Prescription(Name, patient.Name, medication);
    }
}

public class Patient
{
    public string Name { get; }
    public Patient(string name) => Name = name;
}

public record Prescription(string DoctorName, string PatientName, string Medication);

Association (and dependency, its weaker cousin above) can be one-directional — as above, only Doctor knows about Patient — or bidirectional, where both classes hold a reference to each other. The slides note this is a design choice, not a rule.

Aggregation — "has-a", independent lifetimes

Aggregation is association with ownership, but the owner does not control the child's lifetime. A Department holds a list of Doctors, but each Doctor was created somewhere else and handed in — the giveaway is a constructor or method parameter being stored rather than created.

public class Department
{
    public string Name { get; }
    private readonly List<Doctor> _doctors = new();

    public Department(string name) => Name = name;

    // AGGREGATION: the Doctor object is created OUTSIDE and passed in.
    // Department only keeps a reference — it never owns the Doctor's lifetime.
    public void AssignDoctor(Doctor doctor)
    {
        _doctors.Add(doctor);
        Console.WriteLine($"{doctor.Name} assigned to {Name} department.");
    }
}

Composition — owned lifetimes

Composition is association with ownership and lifetime control: the child cannot outlive the parent. If the parent is destroyed, every child it composed is destroyed with it. The giveaway is a field being constructed inside its owner, not received from outside.

public class Hospital
{
    public string Name { get; }
    private readonly List<Department> _departments = new();
    public IReadOnlyList<Department> Departments => _departments;

    public Hospital(string name) => Name = name;

    // COMPOSITION: the Hospital instantiates the Department ITSELF.
    // If this Hospital object goes away, so does every Department it made.
    public void AddDepartment(string deptName)
    {
        var dept = new Department(deptName);
        _departments.Add(dept);
        Console.WriteLine($"Department '{deptName}' created within {Name}.");
    }
}

The slides' own example is a house and its rooms: destroy the house, the rooms go with it. Control can be direct (the parent's constructor builds the child, as above) or transitive (the parent is handed an already-built child and simply takes over responsibility for destroying it) — either way, the defining fact is that the child's lifetime is bound to the parent's.

Delegation

Delegation is the mechanism that makes composition as powerful for reuse as inheritance. Instead of inheriting behaviour from a parent class, an object holds a reference to a helper object and forwards ("delegates") the work to it. It's composition with a purpose: not just "has-a," but "has-a, and hands off the actual work to it."

Watch what happens when you try to reuse behaviour across combinations using inheritance instead — the classic "class explosion":

public class CreditCardEmailPayment : Payment { /* ... */ }
public class CreditCardSmsPayment   : Payment { /* ... */ }
public class PayPalEmailPayment     : Payment { /* ... */ }
public class PayPalSmsPayment       : Payment { /* ... */ }
// Business now wants Crypto as a payment method and Slack as a
// notification channel. That's 2 more methods x 3 notifiers =
// SIX more classes just to cover the new combinations.

var service = new PaymentService(new PayPal(), new SmsNotifier());
service.ProcessTransaction(250);
// Adding Crypto now costs exactly ONE new class: class Crypto : IPaymentMethod { ... }

public interface IPaymentMethod { string Authorize(decimal amount); }
public interface INotifier      { void Send(string message); }

public class CreditCard : IPaymentMethod
{
    public string Authorize(decimal amount) => $"Charged ${amount} to Credit Card.";
}
public class PayPal : IPaymentMethod
{
    public string Authorize(decimal amount) => $"Charged ${amount} to PayPal account.";
}
public class EmailNotifier : INotifier
{
    public void Send(string message) => Console.WriteLine($"EMAIL: {message}");
}
public class SmsNotifier : INotifier
{
    public void Send(string message) => Console.WriteLine($"SMS: {message}");
}

public class PaymentService
{
    private readonly IPaymentMethod _method;
    private readonly INotifier _notifier;

    // COMPOSITION: the service HAS-A payment method and a notifier.
    public PaymentService(IPaymentMethod method, INotifier notifier)
    {
        _method = method;
        _notifier = notifier;
    }

    public void ProcessTransaction(decimal amount)
    {
        // DELEGATION: the service doesn't know HOW to charge or notify —
        // it forwards the request to whichever object it was handed.
        string receipt = _method.Authorize(amount);
        _notifier.Send(receipt);
    }
}

Inheritance vs. composition

You've now seen both mechanisms solve the "reuse behaviour" problem. Design literature has a strong, often-repeated opinion here:

The phrase "inheritance breaks encapsulation" is worth unpacking with a concrete failure, because it's not obvious from the definition alone. This is the classic fragile base class problem:

public class LoggingList<T>
{
    private readonly List<T> _items = new();

    public virtual void Add(T item)
    {
        Console.WriteLine($"Adding: {item}");
        _items.Add(item);
    }

    // AddRange is implemented IN TERMS OF Add today, so subclasses that
    // override Add automatically see every item logged — even bulk ones.
    public void AddRange(IEnumerable<T> items)
    {
        foreach (var item in items) Add(item);
    }
}

public class AuditedList<T> : LoggingList<T>
{
    public override void Add(T item)
    {
        Console.WriteLine($"AUDIT: {item} added at {DateTime.Now}");
        base.Add(item);
    }
}

// "harmless" performance fix inside LoggingList<T>
public void AddRange(IEnumerable<T> items) => _items.AddRange(items);

Composition avoids this entirely: if AuditedList had instead wrapped a List<T> and delegated to it (like PaymentService did above), there would be no shared implementation to secretly depend on — only a public interface, which is exactly the contract composition never lets you cheat on. This exact scenario — an inheritance hierarchy that quietly breaks when the base class changes — is also the subject of the Liskov Substitution Principle; see Chapter 2 for the "flightless bird" version of this bug.

UML

UML (Unified Modelling Language) is a standard pictorial language for specifying, visualising, and documenting a software design — a blueprint, drawn before (or alongside) the code. It isn't limited to software either; the slides note it's used to model business processes too.

Building blocks

UML defines its vocabulary in three layers: things (the nouns you draw), relationships (the lines connecting them — you've already learned four of these), and diagrams (named collections of things + relationships for a specific purpose).

The five core diagrams

UML defines over a dozen diagram types split into structural modelling (class, object, component, package, deployment...) and behavioural modelling (use case, sequence, activity, statechart...). The slides highlight five as the ones you'll draw constantly. Each one below models the same tiny ATM system, so you can see how the same story looks from five different angles.

Use case diagram

When to draw it: at the very start, for high-level requirements — capturing what the system must do, from the user's point of view, before any classes exist.

Class diagram

When to draw it: for the static design — which classes exist, what they know, and how they're related. This is the diagram every relationship figure in this chapter has already been.

Sequence diagram

When to draw it: to capture the time-ordered flow of messages between objects for one specific scenario — invaluable when the order of calls is exactly the thing you need to get right.

Statechart diagram

When to draw it: when an object's behaviour depends on which state it's currently in, and you need to enumerate the states and the events that move it between them.

Activity diagram

When to draw it: essentially a flowchart for a business process or algorithm — good for showing branching logic and parallel steps at a level above individual method calls.

Chapter quiz

Eight scenarios. Reason about ownership and lifetime before you answer — that's the skill this chapter is really teaching.