Phase 5: Object-Oriented & Modular Thinking · ~30 minutes · Python · uv

Why ML Codebases Are Full of Classes

class MyModel isn't OOP for OOP's sake. It's a consistent shape for 'configure this once, then reuse it on different inputs' — and once you see it, you'll see it everywhere.

Hiring signal: Recognizes the configure-once/reuse-repeatedly class shape on sight in unfamiliar library code

What you will learn

Recognize the 'configure at construction, do the work in a method' pattern common to ML libraries
Explain why this pattern exists: consistent reuse of configured state across different inputs
Predict correct, deliberate error behavior when a method is called out of order
Identify what's configuration vs. what's the 'do the work' method in real (simplified) library-style code

Introduction

Type: Learn Languages: Python Prerequisites: Lesson 01 (Classes and Objects) Time: ~30 minutes

Objective

Learning objectives

Recognize the "configure at construction, do the work in a method" pattern common to ML libraries
Explain why this pattern exists: consistent reuse of configured state across different inputs
Predict correct, deliberate error behavior when a method is called out of order
Identify what's configuration vs. what's the "do the work" method in real (simplified) library-style code

What you're building

A script (configurable_tool.py) that:

Defines a class of your own invention (not SimpleModel or RequestClient) with a clear configuration step in __init__ and a separate method that does the main, repeatable work — for example, a TextFormatter configured with a prefix/suffix, with a .format(text) method, or a RateLimiter configured with a max count, with a .allow() method
Creates one instance, configured once, and calls its "do the work" method at least 3 times with different inputs
Adds a guard (like SimpleModel's is_fitted check) that raises a clear, specific error if the work method is called before some required setup step, and demonstrates that error being raised
Contains a comment explicitly labeling which attributes are configuration, which are accumulated state, and which method is "do the work"

Given this simplified class:

class Pipeline:
    def __init__(self, steps):
        self.steps = steps
        self.run_count = 0

    def run(self, data):
        self.run_count += 1
        for step in self.steps:
            data = step(data)
        return data

Which attribute is configuration, and which is the "do the work" method?

steps is decided once, at construction, describing what the pipeline should do — classic configuration, matching learning_rate and base_url from this lesson's earlier examples. run is called repeatedly, once per actual piece of data, applying that fixed configuration — the "do the work" method. run_count is neither configuration nor the work method itself; it's accumulated state, tracking how many times run has been called, exactly like RequestClient's request_count above.

Unlock the full lesson

You've read the first 2 sections. The rest of this lesson covers The Problem, Check Yourself, Key Terms & Next — plus a hands-on lab, quiz, and project artifact.

Create a free account to unlock Phase 0 and Phase 1 of every course — no credit card.