Overview

Your programs now have several ways to organize work. Functions give behavior a name. Dictionaries and lists give information a structure. Files let that information survive between runs.

As programs grow, another question becomes useful: how should a program organize the operations that belong to a particular thing?

Consider an equipment record:

item = {
    "id": "E10",
    "name": "Camera",
    "category": "media",
    "available": True
}

Several operations belong to this item. It can be borrowed if it is available. It can be returned if it is on loan. It can provide a record for a save file.

We could implement those operations as ordinary functions receiving the dictionary. That remains a valid design. A class offers another way to put state and the behavior that uses it together.

You have already worked with classes and objects — instances of classes. You have used built-in classes such as list, dict, and str. You have created objects by calling those classes, and you have called methods on those objects. This part shows how to define your own classes and methods.

After working through this part, you should be able to define classes whose methods keep their data valid, organize a small application into modules, and test its rules and file operations separately from its user interface.

The structure of this part is as follows:

• Defining Classes and Creating Objects connects the familiar object model with classes, instances, attributes, and self.
• Methods and Valid State gives objects operations that preserve their stated rules.
• Objects Working Together uses collections of objects and composition to model a small system.
• Choosing the Right Abstraction compares ordinary values, dictionaries, functions, and classes, including an AI-proposed design.
• Modules and Program Structure separates source files by responsibility and explains guarded entry points.
• Objects and Persistent Data converts between class instances and the dictionary records that file formats can represent.
• Testing and Refactoring Systems checks state changes, object independence, imports, and file round trips.
• Classes and Games builds Asteroids from moving objects, collision coordination, JSON storage, and a supplied graphical interface.
• Recap and Feedback concludes the core course with a small equipment-library application.

Choose Where to Work

Continue using the Python and IDE setup from Part 5. Choose the environment according to the exercise:

The IDE exercises practise working across source files and inspecting saved data. Download each into its own folder; follow the handout and Part 5’s setup chapter for run commands and submission instructions.

The Inline Editor is also available for these exercises. Browser-generated files are temporary, so check saving and loading within one execution there. Use your IDE to check that saved data survives closing and restarting a program.

Both programming exercises in Classes and Games have a Pyxel preview. Select main.py and choose Run to try the moving objects or play Asteroids. To run their sample checks, select check.py and choose Run as Python. Asteroids becomes playable after firing and collision handling work; saving and loading are later stages.

Recommended Order of Work

For each new idea, predict the result of a small example, run it, and change one input or operation. Then complete the nearby exercises.

After Objects Working Together, check that you can follow a call from a collection to one of its items. Identify which object changes, what the call returns, and which references reach the same object.

After Objects and Persistent Data, check that you can follow an object into a plain record and back into a new object. Explain why a rejected load leaves the current object unchanged.

Keep one working habit in mind:

Follow the method call. Identify what changes. Check the result.