Unit 12: Objects & Program Architecture

A class is not a graduation ceremony for “advanced Python.” Sometimes a dictionary and two functions are the clearer design.

Object-oriented structure becomes useful when a concept has related state and behavior that benefit from a named responsibility boundary.

Follow responsibility, not vocabulary

You will work with classes, instances, attributes, methods, self, construction, mutation, and collaboration between objects/modules. The architecture question is more important than memorizing the syntax:

Which part of the program should own this data and the rules that change it?

A Player object might own a name and score plus behavior that updates or reports its own state. File persistence may belong somewhere else. A console menu almost certainly should not become a method on every domain object just because methods exist.

This Unit also connects objects back to earlier topics: mutable state, function calls, modules, files, tests, and debugging. Objects do not replace those ideas. They reorganize responsibilities among them.

Architecture checkpoint

Draw a small responsibility map for your program. Label the major objects/modules, what state each owns, what behavior it provides, and one interface between parts. Then choose one class decision and defend why it is clearer than a plain dictionary/function design for this program.

Architecture earns its complexity by reducing confusion.