When to make it a class

01 / 06

Laying the tools out

Lay out what this chapter has handed you.

The blueprint … class / __init__ / self
Behaviour … methods / __str__
Inheriting … inheritance / overriding / super()

There is no new grammar left to come. From here it is practice at when to use them. The lists, dictionaries and loops from Chapter 2 come along too.

02 / 06

When a dictionary is enough

Learn about classes and you want to make everything a class. But a dictionary is often plenty.

The rough test is this.

Data you are only carrying about → a dictionary will do
Data that comes together with the work that uses it → make it a class

If all you do is put a name and a score side by side and show them, the dictionary is shorter and easier to read.

student = {"name": "Yui", "score": 82}name = student["name"]score = student["score"]print(f"{name} {score} marks")

Result

Yui 82 marks

03 / 06

What changes when it becomes a class

Things change when the work you do with that data starts piling up. Leave it as a dictionary and functions written around the shape of that dictionary end up scattered all over.

Gather it into a class and the data and the work sit in one place. When you want to know how somebody did, you can ask the person themselves.

class Student:    def __init__(self, name, score):        self.name = name        self.score = score    def grade(self):        if self.score >= 80:            return "good"        return "fair"s = Student("Yui", 82)print(f"{s.name} {s.grade()}")

Result

Yui good

04 / 06

One class, one job

A class is a box that takes anything, so leave it alone and it grows fat. Printing the receipt, sending the email and totalling the takings all end up inside the member class — that is far and away the most common way this goes wrong.

The test is "can I say what this class is in one sentence?". "One member's data, and the judgements about that member" you can say. Start saying "members and receipts and email" and it is time to split it.

05 / 06

Inherit only when it is a kind of something

Inheritance is dangerous when overused too. Decide by saying out loud whether the child is a kind of the parent.

A premium member is a kind of member → you can say it, so inheriting is fine
A basket is a kind of product → you cannot say it. The basket holds products, so holding them in a list is the honest way

Inherit because the code merely looks similar and it will hurt later, every single time.

class Basket:    def __init__(self):        self.items = []    def add(self, name):        self.items.append(name)basket = Basket()basket.add("bread")basket.add("jam")print(len(basket.items))

Result

06 / 06

Reading comes first

Classes are a chapter with a great deal to take in and a payoff that is hard to feel, because a small program gets by on dictionaries and functions alone.

But nearly every library you will ever use is made of classes. When class turns up in somebody else's code, being able to think "that is a blueprint" and "that method came from the parent" is what matters. Being able to read them comes before being able to write them, and that alone is a good return.

Right — ten questions. They get bigger as you go.