Layer 2 Session 15 Object-Oriented Basics

Passing Data via the Constructor

Every value a Country needs must arrive through its constructor, deliberately, at creation time — exactly like React props arrive from a parent. This session makes that discipline explicit.

Data flows in through the constructor, explicitly, every time.

Estimated time: 35–40 minutes · Pre-quiz → Concept → Lab → Commit → Post-quiz

1. Learning Objective

By the end of this session you will be able to:

Explain why requiring all data through __init__ parameters is a deliberate discipline, not an accident
Use keyword arguments when constructing an instance for clarity
Add a simple default value to a constructor parameter
Explain the risk of a class silently reading global state instead of its own constructor arguments
Distinguish "construction-time data" from "data computed later by a method"

2. Pre-Coding Quiz

Answer these before reading the concept explanation or writing any code. It is fine to get these wrong — that is the point. You need 4/5 to proceed to the lab.

Question 1 of 5

Given Country(name="Kenya", region="Africa", population=54000000), why write the argument names explicitly instead of just Country("Kenya", "Africa", 54000000)?

Keyword arguments are required by Python for classes with 3+ parameters They make the call self-documenting and order-independent, which matters as constructors grow Positional arguments are deprecated in modern Python There is no difference; it is purely a style preference with zero benefit

Keyword arguments remove ambiguity — a reader does not need to remember or look up parameter order, and swapping two same-typed values (e.g. two strings) by accident becomes far less likely.

Question 2 of 5

Given def __init__(self, name, region, population=0):, what happens with Country("Kenya", "Africa")?

A TypeError — population is required population is set to 0, the default value population is set to None It fails because region should also have a default

Just like the plain functions from Session 08, a constructor parameter can have a default. Omitting population in the call falls back to 0.

Question 3 of 5

Why is it considered bad practice for a class's __init__ to silently read a global variable instead of receiving that value as a parameter?

Global variables are always slower to access It hides a real dependency, making the class harder to test and harder to understand from its constructor signature alone Python forbids reading globals inside a class It is not actually a problem — this is a myth

If a class quietly depends on a global, you cannot tell what it needs just by reading __init__(self, ...) — and you cannot easily create a second instance with different data, or test the class in isolation. Passing the value in as a parameter makes the dependency visible and explicit.

Question 4 of 5

You want two Country instances that should be genuinely different, e.g. for testing. Which approach is more reliable?

Have __init__ read from a shared global dictionary each time Pass different arguments explicitly into each Country(...) call Both are equally reliable Instances cannot legitimately differ from each other

Explicit construction arguments guarantee each instance gets exactly the data you intended. Reading from shared global state risks all instances accidentally seeing the same (possibly stale, possibly already-mutated) values.

Question 5 of 5

"Construction-time data" (passed into __init__) versus "data computed later" — which is population if it never changes after creation, vs. a method like was_founded_before(year) that computes True/False on demand?

Both should be construction-time data population is construction-time data; was_founded_before's result is computed on demand by a method, not stored Both should be computed by methods, never stored There is no meaningful distinction between the two

Data that describes the object and does not need recomputation belongs in __init__. A value that depends on an argument supplied at call time (like a comparison year) is a method's job, computed fresh each call rather than stored as an attribute.

3. The Concept — Constructor Arguments as an Explicit Contract

Data flows in one direction: explicit arguments in, an initialized instance out. Nothing is read from anywhere else.

Recap: init already does this

Since Session 13, every Country instance has received its data through __init__ parameters. This session is about treating that as a deliberate rule, not an implementation detail — and drawing the parallel to how data flows into a React component as props in the original course.

class Country:
    def __init__(self, name, region, population):
        self.name = name
        self.region = region
        self.population = population

# All data arrives explicitly, at construction time
kenya = Country(name="Kenya", region="Africa", population=54000000)

Keyword arguments for clarity

As a constructor grows past two or three parameters, positional calls become error-prone — it is easy to swap two values of the same type by accident. Keyword arguments (Session 09) remove that risk entirely.

# Risky — easy to accidentally swap two strings
peru = Country("Peru", "Americas", 33000000)

# Safer — self-documenting, order-independent
peru = Country(name="Peru", region="Americas", population=33000000)

A default value on a constructor parameter

Just like any function parameter, a constructor parameter can default to a value when the caller doesn't know it yet.

class Country:
    def __init__(self, name, region, population=0):
        self.name = name
        self.region = region
        self.population = population

unknown = Country(name="New Territory", region="Unclaimed")
print(unknown.population)  # 0 — default used

Why NOT to read global state inside init

A tempting shortcut is to have a class silently pull data from a global variable instead of a parameter. This hides the class's real dependencies and makes every instance implicitly coupled to shared state — exactly the kind of bug Session 05 warned about with shared references.

# Risky pattern — DO NOT do this
DEFAULT_REGION = "Africa"

class RiskyCountry:
    def __init__(self, name):
        self.name = name
        self.region = DEFAULT_REGION  # hidden dependency, not visible in the signature!

# Safer — the dependency is visible right in the constructor call
class Country:
    def __init__(self, name, region):
        self.name = name
        self.region = region

safe = Country(name="Kenya", region="Africa")  # nothing hidden

Why this matters for the project: Every object we build from here forward — including the CountryRepository in Layer 4 — receives its dependencies explicitly through its constructor. This one discipline prevents an enormous class of hard-to-trace bugs later.

4. Lab

Lab objective: Rewrite Country construction to always use keyword arguments, add a default population, and demonstrate why reading global state is risky.

What you will build

A file called construction_lab.py.

Step-by-step instructions

Create the file with a Country class using a default population

# construction_lab.py
class Country:
    def __init__(self, name, region, population=0):
        self.name = name
        self.region = region
        self.population = population

Construct three instances using keyword arguments only

kenya = Country(name="Kenya", region="Africa", population=54000000)
peru = Country(name="Peru", region="Americas", population=33000000)
unknown = Country(name="New Territory", region="Unclaimed")

print(kenya.population, peru.population, unknown.population)

Write the risky global-state version and the safe version side by side

Do not delete either — keep both in the file with comments explaining the difference.

DEFAULT_REGION = "Africa"

class RiskyCountry:
    def __init__(self, name):
        self.name = name
        self.region = DEFAULT_REGION  # hidden dependency

class SafeCountry:
    def __init__(self, name, region):
        self.name = name
        self.region = region

risky = RiskyCountry("Somewhere")
safe = SafeCountry(name="Somewhere", region="Africa")

Prove the risky version breaks when the global changes

Change DEFAULT_REGION after construction and observe what happens to a NEW risky instance versus the existing one.

DEFAULT_REGION = "Europe"
another_risky = RiskyCountry("Somewhere Else")
print(risky.region)          # "Africa" — set before the change
print(another_risky.region)  # "Europe" — silently different, no argument changed!

Write a one-sentence comment explaining why SafeCountry does not have this problem

5. Expected Files Changed

File	Action	Why
`construction_lab.py`	Created	Demonstrates keyword construction, defaults, and the risk of hidden global dependencies.
`docs/sessions/session-15/index.html`	Created	This session document.

If you find yourself editing any other file, stop. This session touches exactly 2 files.

6. Commit Checkpoint

Once the lab is complete and you can explain every line, make this exact commit:

git add construction_lab.py docs/sessions/session-15/index.html
git commit -m "session-15: require explicit constructor arguments instead of hidden global state"

Do not commit until you can answer out loud: "Why did another_risky silently get a different region than risky, even though neither call passed a region argument?"

7. Code Review Checklist

Go through your code line by line and check each item:

Country has a default value for at least one constructor parameter

All construction calls in the file use keyword arguments

Both a RiskyCountry (global state) and SafeCountry (explicit argument) version exist side by side

The bug caused by changing the global after construction is demonstrated and printed

A comment explains why SafeCountry avoids this bug

I can explain every line without looking at the concept section

8. Post-Coding Quiz

Same 5 questions. Take it again now that you have written and run the code. You need 4/5 to mark this session complete.

Question 1 of 5

Given Country(name="Kenya", region="Africa", population=54000000), why write the argument names explicitly instead of just Country("Kenya", "Africa", 54000000)?

Keyword arguments remove ambiguity — a reader does not need to remember or look up parameter order, and swapping two same-typed values (e.g. two strings) by accident becomes far less likely.

Question 2 of 5

Given def __init__(self, name, region, population=0):, what happens with Country("Kenya", "Africa")?

A TypeError — population is required population is set to 0, the default value population is set to None It fails because region should also have a default

Just like the plain functions from Session 08, a constructor parameter can have a default. Omitting population in the call falls back to 0.

Question 3 of 5

Why is it considered bad practice for a class's __init__ to silently read a global variable instead of receiving that value as a parameter?

Question 4 of 5

You want two Country instances that should be genuinely different, e.g. for testing. Which approach is more reliable?

Question 5 of 5

9. Reflection Questions

Think through these after the post-quiz. No right answer — they are for discussion.

Where else in the labs so far might you have accidentally relied on a value "just being there" instead of passing it explicitly?
What is the cost of always using keyword arguments (more typing) versus the benefit (clarity, safety)? Where is that tradeoff worth it and where is it not?
How does this session's "explicit data in, explicit instance out" pattern connect back to the reference/mutation lessons from Session 05?
Can you think of a legitimate use for a class reading module-level state, where it would NOT be a hidden dependency problem?

10. What Breaks If This Knowledge Is Missing?

Hard-to-test classes: A class that reads global or module-level state instead of constructor arguments cannot be tested in isolation — every test now depends on setting up (and tearing down) that global correctly, which is exactly the kind of fragile test suite Layer 5 will teach you to avoid.
Composition (Session 16): The next session builds one class out of several others. If each class does not have a clean, explicit set of constructor dependencies, composing them together becomes guesswork instead of straightforward assembly.
The data layer (Layer 4): The CountryRepository we build in Session 28 depends on this discipline directly — it is constructed with its data source as an explicit argument, which is exactly what makes it possible to swap in fake data for tests later.

11. What We Learned

Python concept mastered: Constructor arguments as an explicit, self-documenting contract — keyword arguments, defaults, and the risk of hidden global dependencies.

Unlocks: Every class we build from here forward will receive its dependencies explicitly, making it possible to compose and test them independently.

Next session: Session 16 — Composition — Objects Containing Objects. We build a class whose attribute is itself another object — composing several small classes into a coherent whole.

Passing Data via the Constructor

1. Learning Objective

2. Pre-Coding Quiz

3. The Concept — Constructor Arguments as an Explicit Contract

Recap: __init__ already does this

Keyword arguments for clarity

A default value on a constructor parameter

Why NOT to read global state inside __init__

4. Lab

What you will build

Step-by-step instructions

5. Expected Files Changed

6. Commit Checkpoint

7. Code Review Checklist

8. Post-Coding Quiz

9. Reflection Questions

10. What Breaks If This Knowledge Is Missing?

11. What We Learned

Recap: init already does this

Why NOT to read global state inside init