CHAPTER 5 · 8 lessons · 101 exercises
Classes
Keep data and behaviour together, and make a kind of thing that is yours. This one changes how you design.
When you met dictionaries in Chapter 2 you may have thought: if I want to represent a person or a shop, surely this is enough? For a while, it is. The trouble starts when the work you do with that data piles up.
Say you represent a member as a dictionary. Tidying the name for display, working out the yearly fee, deciding whether they can leave — write each as its own function and the data and the work end up scattered in different places. Change the shape of the member data even slightly and you are off hunting down every function that touches it.
A class is the thing that puts the data and the work in one box. Write down once what a member holds and what a member can do, and from then on you can make as many real ones as you like from that blueprint. The blueprint is the class; a real one made from it is an instance.
In Python you write class Member: to make the blueprint. The first thing inside is a special function called __init__, which is called exactly once, at the moment a real one comes into being. That is where you settle the per-instance values, like what this member is called. A name wrapped in two underscores is Python's mark for "I treat this one specially".
Then there is self. The instance methods you write in this chapter conventionally name their first parameter self. It means the particular one you are dealing with right now. However many members you made from the same blueprint, self.name is that person's name. It looks like an incantation at first; all it is doing is saying out loud whose data we are talking about.
The second half is inheritance, the way you write "almost the same, but slightly different". Build a premium member class on top of the member class and you write only the parts that differ. Replacing an inherited piece of work is overriding, and super() is how you replace it while still calling the original.
Classes are a chapter where there is a lot to take in and the payoff is hard to feel, because a small program gets by on functions alone. But nearly every library you will ever use is made of classes. Being able to read them comes before being able to write them — that alone is worth the trip.
Lessons in this chapter
Build from a blueprint
- 60The data and the work drift apartNo
classyet. Handle members with dictionaries and functions alone, and feel what is awkward about it first.Go to the exercises - 61Write a blueprint, make a real oneUse
classto declare "this is the sort of thing I make". A real one made from it is an instance.Go to the exercises - 62Settling the contents at the moment of birth
__init__is a special function called once, as a real one comes into being. Settle the per-instance values there.Go to the exercises - 63Writing what it can do onto the blueprintA function written inside a class is a method. Put
selffirst and you can write about that real one itself.Go to the exercises - 64Making it printable as it isDefine
__str__andprint(member)gives readable text. What you return has to be a string.Go to the exercises
Inherit from another class
- 65Inherit from another classA class that is almost the same but a little different is one line:
class PremiumMember(Member):.Go to the exercises - 66Override it, and call the parent tooRewriting the original work is overriding.
super()overrides and still calls the original.Go to the exercises - 67When to make it a classThe review for Chapter 5. No new grammar — ten practice questions, thinking about which tool fits.Go to the exercises