Worked Example: A Mortgage Class Hierarchy

This topic's three previous notes each introduced one OOP idea in isolation — a single class, then a subclass, then information hiding. Real code needs all three together, applied to a problem that actually rewards the design. This note builds a small hierarchy of mortgage classes: an abstract Mortgage base class capturing what every mortgage has in common, and three concrete subclasses — a plain fixed-rate mortgage, one with upfront points, and one with a teaser rate that changes partway through — each overriding exactly what makes it different. The point, following Guttag directly, is not to become a mortgage expert; it is to see incremental, class-based design in action on a problem with genuine financial substance, and to close this topic's arc by applying inheritance (Note 2), overriding (Note 2), and information hiding (Note 3) all in one worked build.

Learning objectives. By the end of this note you should be able to:

design an abstract base class that captures shared state and behaviour, intended never to be instantiated directly;
implement subclasses that override __init__ to add subclass-specific setup while reusing the base class's __init__ via an explicit call;
implement a subclass that overrides a behavioural method (make_payment) to change what happens partway through its lifetime, not just at construction;
explain why looking up a closed-form formula from a reputable source, and testing an implementation against an independently computed example, is a discipline worth following whenever a formula (not just code) is a source of correctness risk.

In this lesson

The abstract base class
Three concrete subclasses
Comparing the three mortgages

Before you start

Encapsulation and Information Hiding

The full lesson, with worked examples and exercise solutions, is for members.

Read the full lesson

New to SelfMadeQuant.com? See membership options or browse the Python for Quantitative Finance syllabus.