Why Does `FileHandler` Take a Filename While `PhoneBook` Does Not?

[Rajeev Bagra]

Context Code

class PhoneBookApplication:
    def __init__(self):
        self.__phonebook = PhoneBook()
        self.__filehandler = FileHandler("phonebook.txt")

---

Q1: Why is PhoneBook() created without any parameters?

Answer:
PhoneBook represents an in-memory data structure. Its job is to store names and phone numbers while the program is running.

A typical PhoneBook class looks like this:

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

Since it starts empty and does not depend on any external resource, it does not need any arguments during creation.

In simple terms:

“Create a fresh, empty phonebook in memory.”

---

Q2: Why does FileHandler require a filename as a parameter?

Answer:
FileHandler represents file-related operations, and a file handler cannot exist meaningfully unless it knows which file it is responsible for.

Example:

class FileHandler:
    def __init__(self, filename):
        self.__filename = filename

Passing "phonebook.txt" tells the object:

“You are responsible for reading from and writing to this specific file.”

The filename becomes part of the object’s internal state, so it doesn’t have to be passed again every time a file operation is performed.

---

Q3: If FileHandler does not return anything in its constructor, why create an instance at all?

Answer:
Objects are not created to “return values.”
They are created to hold state and provide behavior.

FileHandler:

• Stores the filename
• Knows how to read from the file
• Knows how to write to the file

Example methods:

filehandler.load_file()
filehandler.save_file(phonebook)

The object itself acts as a service that performs actions when asked.

---

Q4: But only load_file() returns data. Isn’t that inconsistent?

Answer:
No. This is intentional and correct design.

• load_file() → returns data because reading produces information
• save_file() → returns nothing because writing is an action, not a query

This follows normal programming conventions:

• Commands do something
• Queries return something

---

Q5: Why not just use functions instead of a FileHandler class?

Answer:
While functions could work, using a class provides several benefits:

Benefit	Explanation
Encapsulation	All file logic stays in one place
Reusability	Easy to change the file name
Maintainability	File format can change without touching app logic
Clarity	Clear separation of responsibilities

This follows the Single Responsibility Principle:

• PhoneBook → manages data
• FileHandler → manages files
• PhoneBookApplication → coordinates everything

---

Q6: Why is the filename passed once instead of every time?

Answer:
Because the object remembers it.

Instead of writing:

save_file("phonebook.txt", phonebook)

You can write:

filehandler.save_file(phonebook)

This reduces repetition and avoids mistakes.

---

Q7: How do these objects work together conceptually?

Answer:

PhoneBookApplication
├── PhoneBook      → stores contacts in memory
└── FileHandler    → reads/writes contacts to a file

Each class has one clear responsibility, and none of them overlap.

---

Q8: Can you explain this with a real-world analogy?

Answer:

• PhoneBook → a notebook on your desk
• FileHandler → a clerk who knows which file cabinet to use
• "phonebook.txt" → the label on the cabinet

You don’t ask the notebook where files are stored.
You don’t ask the clerk to memorize phone numbers.

Each does its own job.

---

Final Takeaway

FileHandler("phonebook.txt") exists not to return values, but to bind file-related behavior to a specific file.

That is why:

• PhoneBook() needs no parameters
• FileHandler must receive a filename
• The design is clean, scalable, and maintainable

---

[Author]

Posts