Lesson 18B: OOP Deep Dive

NESA In OOP, objects don't share memory directly — they communicate by sending messages. A message is just a method call: you name the receiver, the method, and any arguments.

You've been doing this the whole time without the vocabulary for it.

cart.add_item("Sword")       # message: add_item, sent to: cart, argument: "Sword"
cart.get_total()             # message: get_total, sent to: cart, no arguments
history.push(last_action)   # message: push, sent to: history, argument: last_action

Each line sends a message to an object. The object receives it and decides what to do — using its own internal state. You don't need to know how cart stores its items internally; you just send the message and trust it to respond.

Messages can return a reply

Some messages just trigger an action (like cart.clear()). Others send a value back — that's the return message.

total = cart.get_total()         # return message: the total price (a float)
prediction = model.predict(X)   # return message: an array of predictions
score = model.score(X, y)       # return message: a float between 0 and 1

The sender stores the reply in a variable and carries on. The receiver's internal state is its own business — you only see what it chooses to send back.

NESA Generalisation is about recognising that different specific things share common behaviour — and designing your code around that shared interface rather than the specific details.

You already know inheritance: a Dog and a Cat are both Animal. That's a generalisation — "Animal" captures what they have in common.

Generalisation goes further: even without a shared parent class, objects can be treated the same if they respond to the same messages.

Every scikit-learn model is a generalisation in action

Three completely different algorithms — but you use them identically because they all respond to the same messages:

Because they share this interface, you can write a single function that works with any of them — without knowing which one it is:

def evaluate_model(model, X_train, X_test, y_train, y_test):
    model.fit(X_train, y_train)
    return model.score(X_test, y_test)

# Works with any model — the function doesn't care which one
r2  = evaluate_model(LinearRegression(), X_train, X_test, y_train, y_test)
acc = evaluate_model(LogisticRegression(), X_train, X_test, y_train, y_test)
acc = evaluate_model(MLPClassifier(), X_train, X_test, y_train, y_test)

NESA A facade is a class that wraps one or more complex subsystems behind a simpler interface. The caller doesn't need to know what's happening inside — they just talk to the facade.

The name comes from architecture: a building's facade is its front face. You see a clean, simple exterior. Behind it is all the pipes, wiring, and structure — complex, but hidden.

Without the facade, every time you use the model you have to remember to scale the data, use fit_transform on training data but only transform on test data, and keep the scaler object around. Easy to forget; easy to get wrong.

With a facade, all of that is handled internally — once, correctly. Callers just call train() and predict().

from sklearn.preprocessing import StandardScaler

class MLPipeline:
    """Facade: hides the scaler + model complexity."""

    def __init__(self, model):
        self._model = model          # private — callers don't touch these directly
        self._scaler = StandardScaler()

    def train(self, X, y):
        X_scaled = self._scaler.fit_transform(X)   # fit AND transform on training data
        self._model.fit(X_scaled, y)

    def predict(self, X):
        X_scaled = self._scaler.transform(X)        # transform only — scaler already fitted
        return self._model.predict(X_scaled)

    def evaluate(self, X, y):
        X_scaled = self._scaler.transform(X)
        return self._model.score(X_scaled, y)


# The caller's view — clean, no scaler knowledge needed
pipeline = MLPipeline(LogisticRegression())
pipeline.train(X_train, y_train)
print(pipeline.evaluate(X_test, y_test))

NESA These are two strategies for deciding where to start when designing a system.

Top-down

Start with the big picture. Define what the whole system does, then decompose it into smaller parts. Each part gets broken down further until you reach pieces small enough to implement.

Bottom-up

Start with the small pieces. Build and test individual components first, then combine them into larger subsystems, then combine those into the final system.

In practice, most experienced developers do both: top-down to understand the structure and decide what to build, bottom-up to actually build and test it. You sketch the big picture first so you know what the small pieces need to do — then you implement from the bottom up because you can test each piece before combining them.

These four concepts aren't abstract theory — here's exactly where you'll see each one in the next lesson: