📘 From Dictionary of Lists to Dictionary of Objects: Phone Book Explained (Python MOOC 2025) – revised

[Rajeev Bagra]

In the early stages of the Python MOOC course, learners build a simple phone book using only basic data structures.

The internal data structure looks like this:

all_persons = {}

# Example entries
all_persons["Eric"] = ["02-123456", "045-4356713"]
all_persons["Emily"] = ["040-324344"]

Here:

• Keys → Person names
• Values → Lists of phone numbers

This design is called a dictionary of lists.

It works well for small programs. However, in Part 10 of the course, new requirements are introduced, such as storing addresses and improving maintainability. At this stage, this structure becomes difficult to manage.

To solve this, the course introduces objects inside dictionaries.

📌 Official course page:
https://programming-25.mooc.fi/part-10/4-application-development/

---

❓ Q1: Why is a dictionary of lists no longer enough?

Answer:

A dictionary of lists stores only raw data. When new features are added, the data becomes scattered and difficult to manage.

Problems include:

• No clear structure
• Difficult extension
• More chances of bugs
• Poor readability

Objects allow related data and behavior to be grouped together.

---

❓ Q2: What does “dictionary of objects” mean?

Answer:

It means that instead of storing lists as values, the dictionary stores objects.

Before

name → list of numbers

After

name → Person object

Example:

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

Each Person object manages its own data.

---

❓ Q3: Why do we need a Person class?

Answer:

A Person class represents one real person in the phone book.

It is responsible for:

• Storing the name
• Managing phone numbers
• Storing the address

This follows the single-responsibility principle.

---

❓ Q4: What is the basic Person class?

Answer:

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 class encapsulates personal data.

---

❓ Q5: How does the PhoneBook class connect with Person?

Answer:

The key connecting line is:

self.__persons[name] = Person(name)

This line creates a Person object and stores it inside PhoneBook.

It establishes the relationship between the two classes.

---

❓ Q6: How does the PhoneBook class change?

Answer:

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

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

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

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

It now manages Person objects instead of lists.

---

❓ Q7: Why is .get(name) used in get_entry()?

Answer:

return self.__persons.get(name)

This safely returns:

• A Person object if found
• None if not found

It prevents runtime errors and simplifies validation.

---

❓ Q8: How does searching work now?

Answer:

The user interface retrieves a Person object:

person = phonebook.get_entry(name)

if person is None:
    print("number unknown")
else:
    for number in person.numbers():
        print(number)

The UI no longer works with raw lists.

---

❓ Q9: Why does the user interface not change much?

Answer:

Because of separation of concerns.

• UI → user interaction
• PhoneBook → data management
• Person → personal data

Only internal structures change.

---

❓ Q10: Why does the course recommend “baby steps” in refactoring?

Answer:

Structural changes affect many parts of a program. Changing everything at once often leads to hidden bugs.

The safe approach is:

1. Implement Person
2. Test
3. Update PhoneBook
4. Test
5. Update UI

This mirrors professional development practice.

---

❓ Q11: How is this related to the ExerciseCounter example?

Answer:

Both examples use the same design pattern:

dictionary → object → methods

Example:

students[name] = ExerciseCounter()
students[name].done()

Phone book:

all_persons[name] = Person(name)
all_persons[name].add_number("123")

The idea is identical.

---

[Author]

Posts