Session 24 - Methods & Encapsulation

Discussion prompt

Before we open Session 24 - Methods & Encapsulation: without looking back, what was the main idea of Session 23 - Classes & Objects, and what could you do by the end of it that you could not do before?

Hint: One sentence for the idea, one for the skill. If the second one is blank, that is the part to revisit.

Discussion prompt

An object holds data in its attributes. A method is a function attached to the class that acts on that object's attributes through self.

That is stated as though it always holds. Do one of two things: produce a case where it fails, or say precisely what rules such a case out. "It just does" is not on the menu.

Hint: Hunt at the extremes first — zero, one, negative, empty, equal. If every extreme survives, the reason they survive is the proof.

Discussion prompt

Explain Two jobs: read or change by analogy to something with no Python Fundamentals in it at all — a queue, a recipe, a map, a bank balance, whatever fits. Then say where your analogy breaks.

Hint: An analogy that never breaks is not an analogy, it is the same idea wearing a hat. Find the seam — that is the part that is actually new.

Put in order

Put the moves of A counter: one reader, one mutator into the order they have to happen.

1. value() reads, increment() mutates
2. Two increments raise count from 0 to 2
3. Trace c.count as the calls run

Why: These are the moves of the worked example in the order it makes them, and each one is set up by the one before it. value returns self.count untouched; increment adds 1 to self.count.

Comparison matrix

From A counter: one reader, one mutator: refill the c.count before column from what you know. The rest of the table is as it appeared.

Discussion prompt

Explain A reader is a window; a mutator is a lever to a student a year behind you. No notation, no jargon they have not met — and it still has to be true.

Hint: If your explanation needs a symbol they have never seen, you are describing the notation rather than the idea.

Predict first

The table runs: a.balance() | 50 | 50 · a.balance() | 50 | 50 · a.deposit(10) | 60 | -

In Reading twice does not change anything, given the rows so far: what is the next one — the row where call is a.balance()?

Correct: a.balance() | 60 | 60

Why: The relationship between the columns, not the individual numbers, is what generates the next row. Calling it twice gives 50 both times - nothing moved.

Comparison matrix

From Reading twice does not change anything: every row here is a choice with a cost. Fill the _balance column, then say which row you would actually pick and what you give up for it.

Sort into buckets

Every line below is part of the definition of state or of self — one or the other, never both. Put each where it belongs.

state

The current values of an object's attributes.; Methods either read the state (leave it alone) or mutate it (change it).

self

The first parameter of every method - the instance the method runs on.; obj.method() fills it in automatically.

b1

The current values of an object's attributes. Methods either read the state (leave it alone) or mutate it (change it).

b2

The first parameter of every method - the instance the method runs on. You never pass it by hand; obj.method() fills it in automatically.

Fill in the blanks

From One method uses another — one line has had its right-hand side removed. Put it back.

class Rectangle:
def __init__(self, w, h):
self.w = w
self.h = h
def area(self):
return self.w * self.h
def describe(self):
return "area is " + str(self.area())

r = Rectangle(3, 4)
print(r.area())
print(r.describe())

Why: r is what everything below it consumes, so the wrong expression here fails later and somewhere else. Instead of repeating self.w * self.h, describe reuses the area method through self.

Annotate

Walk the callouts on One method uses another. Each one is a place this is easy to get subtly wrong.

• Instead of repeating self.w * self.h, describe reuses the area method through self.
• Verified by execution: 12, then area is 12.

Draw it

Draw what A method that calls deposit twice just did — the shape of it, not the line-by-line working. One picture, labels only where you need them. Then check it against the steps: anything you could not draw is a step you followed rather than understood.

Predict first

A student writes this, and it looks reasonable:

Referring to an attribute by its bare name inside a method.

It is wrong. Say what breaks — and say it before you turn the page.

Correct: They live on the object as self.w and self.h.

Reach the object's data through self.

Why: They live on the object as self.w and self.h. Bare w has no meaning here, so Python raises NameError.

Sort into buckets

These are the pieces of Session 24 - Methods & Encapsulation, out of order. Put each one back under the part of the lesson it belongs to.

Reading vs Mutating State

Every method works on one object's state; Two jobs: read or change; A counter: one reader, one mutator

Methods Calling Methods

self reaches back to the same object; You never pass self by hand; One method uses another

Encapsulation

Hide the internals, expose the behavior; A leading underscore says 'internal'; Expose behavior, not attributes

s1

Reading vs Mutating State is where Session 24 - Methods & Encapsulation puts Every method works on one object's state, Two jobs: read or change, A counter: one reader, one mutator. Knowing which part of the lesson a problem belongs to is most of knowing which method to reach for.

s2

Methods Calling Methods is where Session 24 - Methods & Encapsulation puts self reaches back to the same object, You never pass self by hand, One method uses another. Knowing which part of the lesson a problem belongs to is most of knowing which method to reach for.

s3

Encapsulation is where Session 24 - Methods & Encapsulation puts Hide the internals, expose the behavior, A leading underscore says 'internal', Expose behavior, not attributes. Knowing which part of the lesson a problem belongs to is most of knowing which method to reach for.

Fill in the blanks

An encapsulated account, with the scaffolding fading: two lines are gone now — fill both.

class Account:
def __init__(self, balance):
self._balance = balance
def deposit(self, amount):
self._balance += amount
def balance(self):
return self._balance

a = Account(100)
a.deposit(50)
print(a.balance())

Why: Reproducing these unaided, rather than reading them, is what tells you the method has transferred. Callers use deposit to change money and balance to read it - not the underscore field.

Step through it

Step through An encapsulated account one row at a time. What is driving the change, and what would the row after the last one be?

1. Step 1: call is Account(100)
2. Step 2: call is a.deposit(50)
3. Step 3: call is a.balance()

Step through it

Step through withdraw that respects the balance one row at a time. What is driving the change, and what would the row after the last one be?

1. Step 1: call is Account(100)
2. Step 2: call is a.withdraw(30)
3. Step 3: call is a.balance()

Comparison matrix

From Withdrawing too much is refused: refill the result column from what you know. The rest of the table is as it appeared.

Fill in the blanks

From A refused withdrawal leaves state intact — one line has had its right-hand side removed. Put it back.

class Account:
def __init__(self, balance):
self._balance = balance
def withdraw(self, amount):
if amount > self._balance:
raise ValueError("insufficient funds")
self._balance -= amount
def balance(self):
return self._balance

a = Account(50)
try:
a.withdraw(80)
except ValueError:
print("blocked")
print(a.balance())

Why: a is what everything below it consumes, so the wrong expression here fails later and somewhere else. So the invariant holds: the balance was never lowered.

Step through it

Step through A refused withdrawal leaves state intact one row at a time. One of these columns never changes — find it, and say why it cannot.

1. Step 1: step is Account(50)
2. Step 2: step is a.withdraw(80)
3. Step 3: step is a.balance()

Predict first

A student writes this, and it looks reasonable:

Reaching past the method and setting the internal field yourself.

It is wrong. Say what breaks — and say it before you turn the page.

Correct: Writing a._balance directly skips withdraw's check, so nothing stops a negative balance.

Go through the method so the guard runs.

Why: Writing a._balance directly skips withdraw's check, so nothing stops a negative balance. The invariant is silently broken - no error, just bad data.

Match the pairs

Match each term to the definition this lesson gave it — not the one you would guess from the word.

• t1. state
• t2. self
• t3. encapsulation
• t4. invariant
• t5. instance attribute

• d1. The current values of an object's attributes. Methods either read the state (leave it alone) or mutate it (change it).
• d2. The first parameter of every method - the instance the method runs on. You never pass it by hand; obj.method() fills it in automatically.
• d3. Bundling data with the methods that manage it, and keeping the data behind those methods so every change goes through a controlled path.
• d4. A condition an object promises to keep true. Methods must never leave the object in a state that breaks it.
• d5. A value stored on a single object (self.name). Two instances can hold different values for the same attribute name.

Why: These are the working definitions of state, self, encapsulation, invariant, instance attribute as Session 24 - Methods & Encapsulation uses them. Pairing them correctly is the test of whether you could state each one with the slide switched off.

Draw it

Draw what Change the class attribute, all see it just did — the shape of it, not the line-by-line working. One picture, labels only where you need them. Then check it against the steps: anything you could not draw is a step you followed rather than understood.

Step through it

Step through A shared counter of instances one row at a time. What is driving the change, and what would the row after the last one be?

1. Step 1: event is Robot("R1")
2. Step 2: event is Robot("R2")
3. Step 3: event is Robot("R3")

Discussion prompt

Explain How Python looks an attribute up to a student a year behind you. No notation, no jargon they have not met — and it still has to be true.

Hint: If your explanation needs a symbol they have never seen, you are describing the notation rather than the idea.

Discussion prompt

Explain A mutable class attribute is shared, too by analogy to something with no Python Fundamentals in it at all — a queue, a recipe, a map, a bank balance, whatever fits. Then say where your analogy breaks.

Hint: An analogy that never breaks is not an analogy, it is the same idea wearing a hat. Find the seam — that is the part that is actually new.

Fill in the blanks

The surprise: one append, two objects, with the scaffolding fading: two lines are gone now — fill both.

class Basket:
items = []
def add(self, item):
self.items.append(item)

a = Basket()
b = Basket()
a.add("apple")
print(a.items)
print(b.items)

Why: Reproducing these unaided, rather than reading them, is what tells you the method has transferred. a and b never get their own; self.items.append mutates the shared list in place - no assignment, so no instance copy is made.

Annotate

Walk the callouts on The surprise: one append, two objects. Each one is a place this is easy to get subtly wrong.

• a and b never get their own; self.items.append mutates the shared list in place - no assignment, so no instance copy is made.
• Verified by execution: ['apple'] twice - b got a's apple, the classic surprise.

Predict first

A student writes this, and it looks reasonable:

Putting the list in the class body, where all instances share it.

It is wrong. Say what breaks — and say it before you turn the page.

Correct: There is only one items list, shared by every Basket.

Create the list per object, inside __init__.

Why: There is only one items list, shared by every Basket. a.add mutates it, so b.items is not empty. Leaky, hard-to-find bug.

Sort into buckets

Some of these hold up and some are the exact mistakes this lesson is built to prevent. Sort them.

Holds up

An object holds data in its attributes. A method is a function attached to the class that acts on that object's attributes through self.; A reader looks at the state and hands back a value - it does not change anything. A mutator changes the state and usually returns nothing.; A reader is a window: you look in and see the value, but looking never changes what is inside. Call it twice and you get the same answer.

Breaks

Referring to an attribute by its bare name inside a method.; Reaching past the method and setting the internal field yourself.

sound

These are stated as this lesson states them — each one survives the edge cases Session 24 - Methods & Encapsulation puts it through.

flawed

Each of these is lifted from a trap in this deck: reasonable-sounding, and wrong in a way that only shows up once you rely on it.

Predict first

The table runs: a.items | ['apple', 'bread'] · b.items | ['apple', 'bread']

In Both baskets pour into one list, given the rows so far: what is the next one — the row where print is Basket.items?

Correct: Basket.items | ['apple', 'bread']

Why: The relationship between the columns, not the individual numbers, is what generates the next row. a and b both mutate Basket.items, so all three prints show both items.

Comparison matrix

From Both baskets pour into one list: every row here is a choice with a cost. Fill the output column, then say which row you would actually pick and what you give up for it.

Fill in the blanks

From The fix keeps them independent — one line has had its right-hand side removed. Put it back.

class Team:
def __init__(self, name):
self.name = name
self.members = []
def add(self, m):
self.members.append(m)

a = Team("Red")
b = Team("Blue")
a.add("Sam")
print(a.members)
print(b.members)

Why: a is what everything below it consumes, so the wrong expression here fails later and somewhere else. Each Team gets a brand-new list, so a's roster is separate from b's.

Comparison matrix

From The fix keeps them independent: refill the a.members column from what you know. The rest of the table is as it appeared.

Discussion prompt

Class body: constants and immutable shared defaults (species = "...", a shared counter you reassign). Per-object mutable state (lists, dicts, sets): make it in __init__ with self.

That is stated as though it always holds. Do one of two things: produce a case where it fails, or say precisely what rules such a case out. "It just does" is not on the menu.

Hint: Hunt at the extremes first — zero, one, negative, empty, equal. If every extreme survives, the reason they survive is the proof.

Discussion prompt

Outside this lesson: where does Session 24 - Methods & Encapsulation actually turn up? Name one concrete situation — a job, a piece of software someone ships, a decision somebody has to make — and say which part of Class attribute or instance attribute? is doing the work in it.

Hint: Vague is the failure mode here. "Engineering" is not a situation; "deciding whether this build is fast enough to ship" is.

Check your understanding

What does this print?

• A. 3 (correct)
• B. 0
• C. None
• D. 1

Answer: A

Why: increment() adds 1 to self.count each call; three calls make count 3, and value() returns it. Verified by execution.

Why B tempts people

count starts at 0, but the three increment calls raise it before value() reads it.

Why C tempts people

value() has a return, so it hands back the number 3, not None.

Why D tempts people

All three increments run on the same object c, so they stack to 3, not 1.

Check your understanding

What does this print?

• A. area is 10 (correct)
• B. area is 7
• C. 10
• D. NameError: name 'area' is not defined

Answer: A

Why: describe() calls self.area(), which returns 5 * 2 = 10, then builds the string. Verified by execution.

Why B tempts people

area multiplies the sides (5 * 2 = 10); it does not add them (5 + 2 = 7).

Why C tempts people

describe wraps the number in the text 'area is ', so the output is the full string, not just 10.

Why D tempts people

area is reached correctly through self.area(); the self. prefix is present, so there is no NameError.

Check your understanding

What does print(b.items) show?

• A. ['apple'] (correct)
• B. []
• C. None
• D. AttributeError

Answer: A

Why: items is one list shared by every Basket. a.add appends to that shared list in place, so b.items sees the apple. Verified by execution.

Why B tempts people

[] would be right only if each object had its own list - but the list lives in the class body, so it is shared.

Why C tempts people

b.items is a real list, not None; append mutated it rather than replacing it.

Why D tempts people

items exists (on the class), so accessing b.items is fine - no AttributeError.

Check your understanding

What does print(b.items) show now?

• A. [] (correct)
• B. ['apple']
• C. None
• D. ['apple', 'apple']

Answer: A

Why: self.items = [] runs once per object, so a and b each own a separate list; adding to a leaves b empty. Verified by execution.

Why B tempts people

That was the shared-class-attribute bug. With the list built in __init__, each object has its own, so b stays empty.

Why C tempts people

b.items is its own empty list, not None.

Why D tempts people

Only a received an apple; b's list was never touched, so it holds nothing.

Check your understanding

What are the two lines of output?

• A. blocked then 50 (correct)
• B. blocked then -30
• C. 50 then blocked
• D. blocked then 0

Answer: A

Why: 80 > 50 so withdraw raises before subtracting; except prints blocked, and the balance was never lowered, so it stays 50. Verified by execution.

Why B tempts people

The raise happens before self._balance -= amount, so the subtraction never runs; the balance is not -30.

Why C tempts people

The withdraw call (and its raise) runs first, so blocked prints before the balance line.

Why D tempts people

The balance is untouched at 50, not reset to 0 - the guard stopped the change entirely.

Check your understanding

What does this print?

• A. 3 3 (correct)
• B. 4 4
• C. 3 4
• D. 4 3

Answer: A

Why: legs is a class attribute, so a and b both look it up on Dog; changing Dog.legs updates the value both see. Verified by execution.

Why B tempts people

The assignment Dog.legs = 3 changed the class attribute, so neither instance still reads 4.

Why C tempts people

Neither instance has its own legs; both fall back to the same class attribute, so they cannot differ.

Why D tempts people

Same reason - there is one shared legs, so both print 3, not one each.

Check your understanding

What does this print?

• A. 3 4 4 (correct)
• B. 3 3 3
• C. 3 4 3
• D. 3 3 4

Answer: A

Why: Assigning a.legs = 3 creates an instance attribute on a that shadows the class one; b and Dog still see the original 4. Verified by execution.

Why B tempts people

Assigning through the instance does not change the class attribute, so b and Dog remain 4.

Why C tempts people

Dog.legs is unchanged at 4 - only a got its own instance attribute; Dog is not 3.

Why D tempts people

b never got its own legs, so it still reads the class value 4, not 3.

Draw it

One page, no notation unless you need it: draw how these connect — Reading vs Mutating State · Methods Calling Methods · Encapsulation · Protecting an Invariant · Class vs Instance Attributes · The Shared-Mutable Trap. Put an arrow wherever one of them is what makes another possible, and label the arrow with why.