Goal

Before writing any code for a real program, you’ll practice planning its structure in plain language first, directly applying the function/class-organization thinking from Parts 3 and 4.

Learn

Jumping straight into code without planning is exactly how a program’s structure becomes tangled — not because the individual pieces of Python knowledge are missing, but because the order and organization weren’t decided first. A genuine planning pass, before any code, means answering: what are the distinct pieces of data this program needs to track? Should any of them naturally be a class (Part 4.1), if they represent a genuine “thing” with both data and behavior, or are plain variables/lists/dictionaries (Parts 1-2) sufficient? What are the distinct actions the program performs — and should each genuinely be its own function (Part 3.1), rather than one large block of code doing everything at once?

For example, planning a simple contact book program might identify: a Contact class (name, phone, email — genuinely a “thing” with attributes), a list to hold multiple Contact objects, and separate functions for add_contact(), find_contact(), and remove_contact() — each a distinct, genuinely separate action, rather than one giant tangled block of code handling every possible action inline.

This planning step directly determines the actual code structure that follows — skipping it is exactly how programs end up as one long, hard-to-follow script instead of clearly organized, genuinely reusable pieces.

Decision Task

You’re planning a simple to-do list program: adding tasks, marking them complete, and listing all tasks. Before reading on: would a single Task genuinely benefit from being its own class, or would a plain list of strings be sufficient?

Show Answer

A class genuinely makes sense here, since a Task has multiple related pieces of data (the task description, and a completed True/False status) plus behavior (marking as complete) — exactly the “data and behavior bundled together” pattern from Part 4.1 that classes are designed for. A plain list of strings could only hold the description, with no clean way to track each task’s completion status alongside it.

Common Mistake

Starting to write actual code before deciding whether a given piece of data genuinely needs to be its own class, or whether a simpler structure (list, dictionary) is sufficient. This is exactly how programs end up with either unnecessarily complex classes for simple data, or tangled, hard-to-track plain variables for data that genuinely needed a class’s structure — both stemming from skipping the deliberate planning step.

Practice Questions

1. Plan (in plain language, no code) the structure of a simple library book-tracking program: what data needs tracking, and would any of it benefit from being a class?

Show Answer

Reasonable plan: a Book class (title, author, is_checked_out — genuine data + behavior), a list holding multiple Book objects, and separate functions like checkout_book() and return_book() for the distinct actions.

2. Why might a program tracking simple settings (like volume=50, brightness=80) NOT need a class, unlike the Contact example?

Show Answer

These are simple, independent values with no shared behavior or meaningful bundled relationship the way a Contact’s name/phone/email do — a plain dictionary is likely sufficient, without the added complexity of a class definition.

3. In the contact book example, why are add_contact(), find_contact(), and remove_contact() each their own separate function rather than one large combined function?

Show Answer

Each represents a genuinely distinct action; separating them makes each one focused, testable independently (Part 5.4), and reusable on its own, rather than one large function trying to handle every possible action inline.

4. True or False: every piece of data in a program should always be organized into its own class.

Show Answer

False — plain variables, lists, and dictionaries are often genuinely sufficient; a class is the right choice specifically when data and related behavior naturally belong bundled together as one “thing.”

5. What two planning questions does this lesson suggest asking before writing any code?

Show Answer

What distinct data does the program need to track, and should any of it be a class? What distinct actions does it perform, and should each be its own function?

Try It Yourself

Before moving to the next lesson, plan out (in plain language) the structure of a simple expense tracker program of your own choosing — what data would it track, would any of it be a class, and what separate functions would it need? This isn’t graded, but skipping it will make the next lesson’s build harder to follow concretely.

This is an open, ungraded reflection exercise — there is no single correct answer to reveal.

Quick Check

1. What should happen before writing any code for a new program, according to this lesson?

Show Answer

A plain-language planning pass identifying the program’s genuine data structures and distinct actions.

2. When does a piece of data genuinely benefit from being its own class, rather than a plain variable or list?

Show Answer

When it has multiple related pieces of data plus behavior naturally bundled together, like a Task with both a description and a completed status.

3. Why might a set of simple, independent settings not need a class?

Show Answer

They lack meaningful shared behavior or a bundled relationship, making a plain dictionary sufficient.

4. Why should distinct actions each get their own function, rather than one combined function handling everything?

Show Answer

Each stays focused, independently testable, and reusable, rather than creating one large tangled function.

5. Does skipping the planning step only matter for complex programs?

Show Answer

No — even simple programs benefit, since planning is exactly what prevents unnecessarily complex or tangled structure regardless of program size.