From Lists to Objects: Building a Scalable Phone Book (Python MOOC 2025)

[Rajeev Bagra]

📘 Phone Book with Objects in a Dictionary – Q&A Guide (MOOC.fi Part 10)

🧠 Initial Context

In the Python Programming MOOC 2025, Part 10 covers building larger applications with object-oriented design. One example in this section is a phone book application originally implemented using lists and dictionaries. In the next exercise, you are asked to change the phone book so that the values in the dictionary are objects, not lists — a foundational object-oriented concept. ([programming-25.mooc.fi][1])

👉 Read the core material here:
📄 Developing a larger application – Phone book section:
https://programming-25.mooc.fi/part-10/4-application-development/ ([programming-25.mooc.fi][1])

Part 10 overview (including object-oriented techniques) is here:
📄 Part 10: Developing a larger application:
https://programming-25.mooc.fi/part-10/ ([programming-25.mooc.fi][2])

---

❓ Q1: Why is storing objects in a dictionary better than storing lists?

Answer:
Using simple lists works fine for a small number of fields, but as your application grows (e.g., phone numbers and addresses), managing related data across multiple lists becomes messy and error-prone.

By using objects, you encapsulate all data and behavior for a person inside a single entity. This makes your code more organized, easier to maintain, and scalable — exactly what object-oriented design is for. ([programming-25.mooc.fi][1])

---

❓ Q2: What does “objects in a dictionary” mean?

Answer:
It means the dictionary keys remain names, but instead of values being lists of numbers, they become instances of a class — e.g., Person objects.

📍 Before:

phonebook["Eric"] = ["02-123456", "045-4356713"]

📍 After:

phonebook["Eric"] = Person("Eric")

This allows storing numbers, addresses, and future fields together inside the Person object. ([programming-25.mooc.fi][1])

---

❓ Q3: How do we design the Person class?

Answer:
This class holds the name, phone numbers, and address for a person:

class Person:
    def __init__(self, name: str):
        self.__name = name
        self.__numbers = []
        self.__address = None

    def name(self):
        return self.__name

    def numbers(self):
        return self.__numbers

    def address(self):
        return self.__address

    def add_number(self, number: str):
        self.__numbers.append(number)

    def add_address(self, address: str):
        self.__address = address

This design makes it easy to expand the phone book later (e.g., emails, birthdays) without changing the overall app logic. ([programming-25.mooc.fi][1])

---

❓ Q4: How does the PhoneBook class change?

Answer:
Previously, it stored lists directly. Now it stores Person objects:

class PhoneBook:
    def __init__(self):
        self.__persons = {}

    def add_number(self, name: str, number: str):
        if name not in self.__persons:
            self.__persons[name] = Person(name)
        self.__persons[name].add_number(number)

    def add_address(self, name: str, address: str):
        if name not in self.__persons:
            self.__persons[name] = Person(name)
        self.__persons[name].add_address(address)

    def get_entry(self, name: str):
        return self.__persons.get(name)

This keeps phone book logic centralized and consistent. ([programming-25.mooc.fi][1])

---

❓ Q5: How does this affect the user interface?

Answer:
Very little. The UI still asks for name, number, and address the same way. The difference is that the UI now accesses object methods like .numbers() and .address() instead of raw list operations.

This is separation of concerns:

• UI handles interaction
• PhoneBook handles storage
• Person holds the data
  — all cleanly separated. ([programming-25.mooc.fi][1])

---

❓ Q6: What do tests look like after this change?

Answer:
Testing becomes cleaner too:

pb = PhoneBook()
pb.add_number("Eric", "02-123456")
entry = pb.get_entry("Eric")
print(entry.numbers())    # ['02-123456']
print(entry.address())    # None

If no entry exists:

print(pb.get_entry("Emily"))    # None

This shows whether data is stored and retrieved correctly without UI. ([programming-25.mooc.fi][1])

---

❓ Q7: Why does the course recommend “baby steps and testing”?

Answer:
When making structural changes like this, it’s easy to introduce bugs if you try to do everything at once. The course strongly encourages iterative changes with testing after each step to ensure reliability and avoid regressions. ([programming-25.mooc.fi][1])

---

🏁 Summary: Main Lessons

✔ Objects group data and behavior neatly
✔ Dictionaries can store objects, just like lists
✔ Separation of concerns makes large programs manageable
✔ Refactoring step-by-step with tests prevents bugs

---

💡 Direct MOOC.fi References for Learners

• 📄 Phone book section (Objects in a dictionary)
  https://programming-25.mooc.fi/part-10/4-application-development/ ([programming-25.mooc.fi][1])

• 📄 Part 10 overview (OOP & larger apps)
  https://programming-25.mooc.fi/part-10/ ([programming-25.mooc.fi][2])

---

[Author]

Posts