Week 6 · Tuesday, October 6, 2026 (Monday schedule) · Room D-221
You have been using objects since your first blink.
Every LED(17) and Button(27) you have typed was an object: a little capsule holding its own state and offering its own behaviour. Today you stop renting them and start building your own. Last week's flags, modes and functions move in together, and your programs get the shape they will keep for the rest of the course.
What happens today
Theory · first hour
From using objects to making them
What an object is (state plus behaviour, in one capsule), how the gpiozero objects you already use are built, the class keyword, __init__ and the famous self, and how last week's state machines become clean classes.
Lab · two hours
Refactor the reaction timer
Same system as Week 5, better architecture: a ReactionLog class that keeps scores, a ReactionGame class that owns the hardware, your first module, and Week 5's verification table re-run to prove the refactor changed structure without changing behaviour. Then a spec-first ladder of classes you design yourselves.
In the course outline
This is Week 6 of 420-302-VA, on a Tuesday running the Monday schedule (no class Monday October 5). It is the last week of new material before the midterm on Monday, October 19 (Week 7; no class October 12), which covers Weeks 1 to 6, and before the reflection log due the same day. Everything after the break builds on classes: Week 9's MQTT client is an object whose callbacks you set, Week 11's Flask app is an object, and the project's control program will be a handful of classes you design with Week 5's methods and this week's tools.
Why objects, and why now
Last week's reaction.py works, and it already creaks. The times live in one variable, the hardware in two more, the false-start logic in the middle of everything; add a second player, or a lockout counter, and loose variables start multiplying, each one global to the whole script, each one changeable from anywhere. Week 5 taught you to name state; this week gives named state a home.
An object is that home: a bundle of related state (attributes) and the behaviour allowed to touch it (methods), living together behind one name. The idea is old and physical. Object-oriented programming grew out of 1960s simulation languages, built to model real things, ships, machines, queues, as software entities with their own state and their own operations (the history runs through Simula and Smalltalk). That origin is why OOP fits automation so naturally: a motor is state (speed, direction, running) plus behaviour (start, stop, reverse). The software twin of a device wants the same shape, and gpiozero's designers gave it exactly that, which is why led.on() read so well in Week 4.
Three concrete payoffs, all of which you will feel today:
- State gets a guardian. The night light's mode can only change through its
press()method, which enforces the rules (the 1 s ignore window). No stray line elsewhere can corrupt it. That discipline has a name, encapsulation, and it is the software version of a guarded control panel. - Two of a thing costs one line. Two players need two score logs:
log_a = ReactionLog(),log_b = ReactionLog(). With loose variables, "two of everything" means duplicating half the script. - Programs read like the system.
game.play_round(),door.open(),sensor.read(): code organized by the things it models is code a stranger, or the midterm's grader, or you in November, can navigate.
Why this course teaches it now
Three weeks of evidence
You have used objects every lab since Week 4: created them, called their methods, read their attributes, set their callbacks. The concept arrives with the experience already banked; today just names what your hands know.
Design just taught you the need
Week 5 ended with state machines: a mode, flags, and the functions that respect them, held together by your discipline alone. A class holds them together by construction. OOP lands best right after the problem it solves has been felt.
Every library ahead assumes it
paho-mqtt (Week 9), Flask (Week 11) and gpiozero's docs all speak fluent OOP: constructors, methods, attributes, callbacks, "Bases:" lines. After today you read those docs as an insider.
Three ideas you will reuse for the rest of the course
Class is blueprint, instance is thing
A class is the recipe; an instance is a cake. LED describes what every LED object has and does; LED(17) bakes one, with its own pin and its own state. Ten instances, one class, zero copied code.
self is just "this one"
Inside a method, self names the instance being operated on. log.add(431) is Python quietly calling ReactionLog.add(log, 431). Once you see that rewrite, self stops being mysterious forever.
Build by containing (has-a)
Your classes will mostly contain gpiozero objects: a NightLight has an LED, has a Button, has a mode. Composition is how small tested pieces become systems, and it is the pattern from here to the final project.
What you will be able to do by the end of the week
- Explain class vs instance, attribute vs method, and read
led = LED(17)as a constructor call. - Explore any object in the REPL with
type(),dir()andhelp(). - Write a class with
__init__, attributes and methods, and explainselfin one sentence. - Create multiple independent instances and predict their separate state, on paper and in the REPL.
- Implement a Week 5 state diagram as a class whose methods are the transitions.
- Split code into your own module and import it, and keep a class-based project verified against its spec.
Words you will hear all day
| Term | Plain meaning | Common mix-up to avoid |
|---|---|---|
| Object / instance | One concrete thing in memory, with its own state and behaviour. | "Object" and "instance" are the same idea; "instance" stresses which class it came from. |
| Class | The blueprint: what attributes and methods every instance of this kind has. | The class is not a thing you switch on; LED.on() without an instance fails. |
| Attribute | A piece of state living on an instance: led.is_lit, self.mode. | Read without parentheses; adding () tries to call it. |
| Method | A function that lives on a class and acts on an instance: led.on(). | Needs parentheses to run; without them you get the method itself, not its effect. |
Constructor / __init__ | The method that runs when an instance is created, setting up its starting state. | Two underscores each side; misspell it and it silently never runs. |
self | Inside a method, the instance being operated on. | You list it in def, but never pass it yourself; Python supplies it. |
| Dot notation | thing.part: reach into an object for its attribute or method. | Chains read left to right: game.log.best() is "the game's log's best". |
| Composition (has-a) | An object holding other objects as attributes. | Different from inheritance (is-a); this course writes has-a and mostly just reads is-a. |
| Inheritance (is-a) | A class built as a specialization of another, receiving its features. | What gpiozero's "Bases:" lines mean; not something you need to write yet. |
| Encapsulation | State changed only through the methods that know its rules. | Python enforces it by convention, not locks; the discipline is yours. |
| Module | A .py file you can import; today, one you wrote. | Import by file name without .py, from the same folder. |
| Refactoring | Improving structure without changing behaviour, proven by re-running the spec's checks. | If the verification table changes, it was not a refactor. |
Where this fits in the course
Week 5 · Sep 28
Requirements and pseudocode
Design before code: the specs, trace tables and state diagrams from last week are exactly what today's classes implement, and the lab re-uses its verification table verbatim.
Week 6 · Oct 6 · this hub
Objects and classes
State and behaviour move in together: reading the objects you own, writing your first classes, state machines as classes, and a refactoring lab with a spec-first ladder.
Week 7 · Oct 19
Midterm and reflection log
On paper, covering Weeks 1 to 6. No class October 12. The hand-in page's review plan maps every hub to what to revise.
Working at home
Half of this week is REPL-and-paper work: ReactionLog and every trace of it run on any computer with Python 3, no hardware needed, and class design (boxes of attributes and methods) is a notebook exercise. The hardware classes reproduce on a home setup from Week 2. With the midterm two weeks out, the best home hour this week is not new material at all: it is the review plan, started early.