Part V: Object-Oriented Programming

Up to this point, you have been thinking about programs as sequences of instructions that operate on data: call this function, pass it this list, get back a result. That model works. You have built real software with it. But there is a fundamentally different way to organize your thinking about programs, and learning it will change how you see code forever.

Object-oriented programming is not just a technique. It is a paradigm shift.

What This Part Covers

Chapter 14: OOP Intro introduces the core idea: objects that bundle data and behavior together. Instead of a dictionary holding a task's fields and a separate function that displays it, you will create a Task object that knows its own data and knows how to display itself. You will define classes, write constructors, implement special methods like __str__ and __repr__, and learn when OOP is the right approach --- and when it is overkill.

Chapter 15: Inheritance and Polymorphism shows you how to build on what exists. When you need a DeadlineTask that behaves like a Task but adds a due date, you do not copy-paste the entire class. You inherit from it and extend. Polymorphism then lets you write code that works with any kind of task --- deadline, recurring, checklist --- without knowing or caring which specific type it is. You will also learn composition as an alternative to inheritance, and the "is-a" vs. "has-a" distinction that guides the choice between them.

Chapter 16: OOP Design elevates you from someone who uses OOP to someone who designs with it. You will encounter the SOLID principles, explore design patterns like Strategy, Observer, and Factory, and learn to use dataclasses for clean, simple data objects. Most importantly, you will develop the judgment to recognize code smells and refactor messy class hierarchies into clean, loosely coupled designs.

Why This Matters

Object-oriented programming is the dominant paradigm in professional software development. Frameworks you will encounter in web development (Django, Flask), data science (pandas), game development (Pygame), and nearly every other domain are built on OOP principles. Understanding classes and objects is not optional for a working programmer --- it is the vocabulary of the field. More than that, OOP gives you tools for managing the complexity of large programs in ways that procedural code simply cannot match.

What You Will Be Able to Do

By the end of Part V, you will be able to:

  • Define classes with attributes, methods, and clean constructors
  • Create class hierarchies using inheritance and method overriding
  • Write polymorphic code that works with any object that supports a given interface
  • Choose between inheritance and composition for a given design problem
  • Apply common design patterns to solve recurring architectural challenges
  • Use dataclasses for simple, readable data objects
  • Refactor procedural code into a well-designed object-oriented structure

How the Chapters Connect

Chapter 14 teaches you the mechanics: classes, objects, methods, self. Chapter 15 introduces the relationships between classes: inheritance, polymorphism, composition. Chapter 16 steps back and asks the design question: given these tools, how do you use them well? The progression moves from "how does OOP work?" to "how do objects relate?" to "how do you build systems that stay clean as they grow?"

Your Progressive Project: TaskFlow

TaskFlow undergoes its most dramatic transformation in Part V. In Chapter 14, you will refactor the entire application from dictionaries and functions into proper classes: Task, TaskList, and TaskStorage (v1.3). In Chapter 15, you will create specialized task types --- DeadlineTask, RecurringTask, and ChecklistTask --- each with polymorphic behavior for display and completion (v1.4). In Chapter 16, you will apply the Observer pattern so that changes to tasks automatically trigger notifications, use dataclasses to simplify your models, and refactor for loose coupling between components (v1.5).

The TaskFlow that emerges from Part V will be architecturally unrecognizable from the script you started with. And that is the point: OOP does not just change your code. It changes how you think about what code can be.

Chapters in This Part