Object-oriented programming II: inheritance, composition, interfaces and design principles

Lesson 4 introduced objects, encapsulation and polymorphism. This lesson covers the ways classes relate to one another. Inheritance lets one class extend another, reusing its code and standing in for it. Composition builds objects out of other objects. Interfaces and abstract base classes state what an object must be able to do without saying how. These tools are powerful and easy to misuse, so the lesson ends with the design principles, known by the acronym SOLID, that experienced programmers use to keep object-oriented code flexible. Software engineering at the scale of teams and large systems is the subject of CMPUT-301; here the focus is on the paradigm's building blocks.

Inheritance: extending a class

A subclass inherits the attributes and methods of its superclass and can add new ones or override inherited ones. Inheritance models an is-a relationship: a savings account is an account, so code that works with accounts should work with savings accounts. Overriding methods is how subclasses specialize behavior, and `super()` lets an overriding method call the superclass version so that the subclass extends rather than replaces it.

class Account:
    def __init__(self, owner, balance=0):
        self.owner, self.balance = owner, balance
    def withdraw(self, amount):
        if amount > self.balance:
            raise ValueError("insufficient funds")
        self.balance -= amount
    def month_end(self):
        pass                                    # nothing by default
    def __repr__(self):
        return f"{type(self).__name__}({self.owner}, {self.balance:.2f})"

class Savings(Account):
    def __init__(self, owner, balance=0, rate=0.02):
        super().__init__(owner, balance)        # reuse the parent's setup
        self.rate = rate
    def month_end(self):                        # override: add interest
        self.balance += self.balance * self.rate / 12

class Everyday(Account):
    FEE = 4.00
    def month_end(self):                        # override: charge a fee
        self.balance -= self.FEE

accounts = [Savings("Ana", 1200), Everyday("Ben", 300), Account("Cy", 50)]
for a in accounts:
    a.month_end()                               # dynamic dispatch picks each override
print(accounts)
print(isinstance(accounts[0], Account), Savings.__mro__[1].__name__)

[Savings(Ana, 1202.00), Everyday(Ben, 296.00), Account(Cy, 50.00)]
True Account

`Savings` reuses `withdraw` and `__repr__` without repeating them, and every subclass can be used wherever an `Account` is expected. The method resolution order, `__mro__`, lists the classes Python searches when looking up an attribute; for single inheritance it is simply the chain of superclasses. Python also allows multiple inheritance, with the order computed by an algorithm called C3 linearization, but most designs are clearer with single inheritance plus composition.

The Liskov substitution principle

Barbara Liskov stated the rule that makes inheritance safe: if code works correctly with objects of a superclass, it must work correctly with objects of any subclass. A subclass may accept more and promise more, but it must not require more of its callers or deliver less than the superclass promised. Violations look harmless and cause surprising bugs, because client code that is correct for the superclass breaks when a subclass object arrives.

Abstract base classes and interfaces

Often a superclass exists only to define what its subclasses must do. An abstract base class declares abstract methods without implementing them, and cannot itself be instantiated. Python's `abc` module provides `ABC` and `@abstractmethod`; a subclass that does not implement every abstract method also cannot be instantiated, so the mistake is caught when the object is created rather than when the missing method is first called. Java has abstract classes and also interfaces, which declare methods and can provide default implementations but hold no instance state.

from abc import ABC, abstractmethod

class Exporter(ABC):
    @abstractmethod
    def export(self, rows): ...
    def export_all(self, tables):            # template method built on export
        return [self.export(rows) for rows in tables]

class CsvExporter(Exporter):
    def export(self, rows):
        return "\n".join(",".join(map(str, r)) for r in rows)

class BrokenExporter(Exporter):              # forgot to implement export
    pass

print(CsvExporter().export_all([[(1, "a"), (2, "b")]]))
for cls in (Exporter, BrokenExporter):
    try:
        cls()
    except TypeError as err:
        print(f"{cls.__name__}: {err}")

['1,a\n2,b']
Exporter: Can't instantiate abstract class Exporter without an implementation for abstract method 'export'
BrokenExporter: Can't instantiate abstract class BrokenExporter without an implementation for abstract method 'export'

`export_all` is a template method: a concrete method in the abstract class that calls the abstract operation, so every subclass gets it for free. This combination, an abstract class that defines the skeleton of an algorithm and subclasses that fill in steps, is one of the most common legitimate uses of inheritance.

Composition over inheritance

Composition builds an object by giving it other objects as parts and delegating work to them. It models a has-a relationship: a car has an engine. The design advice composition over inheritance, popularized by the 1994 book on design patterns by Gamma, Helm, Johnson and Vlissides, reflects hard experience. Inheritance couples a subclass tightly to its superclass's implementation, so a change in the parent can break every child, a problem called the fragile base class. Deep hierarchies also tend to explode: if notifications can be sent by email or text and can be urgent or normal, inheritance needs a class for every combination, while composition needs one object for each choice.

class Email:
    def send(self, to, text): return f"email to {to}: {text}"
class Sms:
    def send(self, to, text): return f"text to {to}: {text[:20]}"

class Urgent:
    def format(self, text): return "URGENT " + text.upper()
class Normal:
    def format(self, text): return text

class Notifier:                       # composed of a channel and a policy
    def __init__(self, channel, policy):
        self.channel, self.policy = channel, policy
    def notify(self, to, text):
        return self.channel.send(to, self.policy.format(text))

for ch in (Email(), Sms()):
    for po in (Urgent(), Normal()):
        print(Notifier(ch, po).notify("ana", "server room temperature high"))
n = Notifier(Email(), Normal())
n.policy = Urgent()                   # policy swapped at run time
print(n.notify("ben", "backup failed"))

email to ana: URGENT SERVER ROOM TEMPERATURE HIGH
email to ana: server room temperature high
text to ana: URGENT SERVER ROOM T
text to ana: server room temperat
email to ben: URGENT BACKUP FAILED

With composition, adding a third channel, say a chat message, adds one class and immediately works with both policies. Behavior can also change at run time by replacing a part, something a fixed class hierarchy cannot do. The cost is a little more wiring: the `Notifier` must be given its parts. Use inheritance for genuine is-a relationships where substitutability holds and the superclass was designed to be extended; use composition for everything else.

The SOLID principles

Robert C. Martin collected five design principles for object-oriented code under the acronym SOLID. They are guidelines, not laws, and each can be overdone, but together they describe code that is easy to extend and hard to break. Each principle is a response to a common way object-oriented systems become rigid.

from typing import Protocol

class SalesSource(Protocol):
    def fetch(self) -> list[tuple[str, float]]: ...

class Sender(Protocol):
    def send(self, body: str) -> None: ...

def monthly_totals(sales):                       # pure business rule
    totals = {}
    for month, amount in sales:
        totals[month] = totals.get(month, 0) + amount
    return dict(sorted(totals.items()))

class ReportGenerator:                           # depends only on abstractions
    def __init__(self, source: SalesSource, sender: Sender):
        self.source, self.sender = source, sender
    def run(self):
        totals = monthly_totals(self.source.fetch())
        self.sender.send("; ".join(f"{m}: {t:.2f}" for m, t in totals.items()))

class FakeSource:                                # test doubles, no database needed
    def fetch(self): return [("2026-02", 120.0), ("2026-01", 80.5), ("2026-02", 30.0)]
class CaptureSender:
    def __init__(self): self.sent = []
    def send(self, body): self.sent.append(body)

cap = CaptureSender()
ReportGenerator(FakeSource(), cap).run()
print(cap.sent)

['2026-01: 80.50; 2026-02: 150.00']

Inheritance and composition in Java

Java supports single inheritance of classes with `extends` and multiple inheritance of interfaces with `implements`. Since Java 17, a class or interface can be `sealed`, listing exactly which subclasses are permitted. Sealing closes a hierarchy so that the compiler knows every variant, which connects object-oriented hierarchies to the algebraic data types of lesson 3: a sealed interface with record implementations is Java's version of an enum with fields, and a switch over it can be checked for exhaustiveness.

public class Sealed {
    sealed interface Payment permits Cash, Card, Transfer {}
    record Cash(double amount) implements Payment {}
    record Card(double amount, String last4) implements Payment {}
    record Transfer(double amount, String bank) implements Payment {}

    static String describe(Payment p) {
        return switch (p) {                        // exhaustive: no default needed
            case Cash c -> String.format("cash %.2f", c.amount());
            case Card c -> String.format("card ending %s, %.2f", c.last4(), c.amount());
            case Transfer t -> String.format("transfer from %s, %.2f", t.bank(), t.amount());
        };
    }

    public static void main(String[] args) {
        Payment[] ps = { new Cash(12.5), new Card(80, "4421"), new Transfer(250, "Northern Credit Union") };
        for (Payment p : ps) System.out.println(describe(p));
    }
}

cash 12.50
card ending 4421, 80.00
transfer from Northern Credit Union, 250.00