Information Hiding in Python: Hide the Decision, Not Just the Field

1. Every field in WatchHistory starts with _. Which statement best describes whether the storage representation is hidden?

• Yes — the leading underscore is Python’s convention for private, so external code cannot access _history.

  The underscore is a convention, not enforcement. But that’s the small problem — the big problem is what the public API returns. The list itself escapes through recent(), no underscore-bypassing needed.

• Yes — the public method recent() is the only way clients see the data, so it is encapsulated.

  Having only one public read method is not the same as hiding. If that method exposes the internal representation by reference, clients can still depend on the representation. Encapsulation (one access point) ≠ information hiding (that access point reveals nothing volatile).

• No — recent() hands back the actual list, so callers can mutate it and depend on its type.
• No — leading underscores have no enforcement in Python at all; everything is public anyway.

  Half right — underscores aren’t enforced. But the deeper leak isn’t ‘someone reaches in to _history directly.’ It is that recent() hands out the list, which is the same thing in effect with no underscore-poking required. Read what the public method returns, not just what’s named with _.

2. Which future change does the current WatchHistory design make expensive — meaning many callers would have to be edited?

• Adding a new dict key, like a rating, alongside title and year.

  Adding a key affects what’s inside each entry, but callers that read existing keys still work. It is a small ripple at worst.

• Renaming the private attribute _history to _titles_watched.

  Renaming an underscore-prefixed attribute is a local change. No caller mentions the attribute name.

• Switching internal storage from list[dict] to dict[str, Episode].
• Adding a brand-new public method like clear().

  Adding a new method extends the public API without breaking existing callers. Open/Closed Principle in action.

3. Which is the most accurate one-line definition of information hiding in Parnas’s sense?

• Marking fields and methods private so external code can’t access them.

  Access modifiers help enforce information hiding when used well, but they don’t define the principle. You can mark every field private and still leak the secret through return types and method signatures.

• Splitting a program into small files and functions.

  Splitting code is modularization. Information hiding is the criterion for how to split — by hidden decisions, not by processing steps.

• Each likely-to-change decision lives in one module, behind a stable interface.
• Returning copies instead of references from getter methods.

  Returning copies prevents one leak (mutation). It is a useful tactic, not the principle itself.

1. In Parnas’s terms, what is Playlist’s secret after your refactor?

• The fact that _tracks is named with an underscore.

  Naming is a clue, not a secret. The secret is a design decision, not a syntactic marker.

• The order in which tracks were added.

  Insertion order may be a behavior the public API promises (e.g., ‘top_tracks ties break by insertion order’), but it is not the central secret. The storage decision behind it is.

• How tracks are stored and how queries like ‘top N by popularity’ are computed.
• The exact value of the popularity threshold for party-readiness (60).

  That threshold is a client policy, owned by app.is_party_appropriate. It lives in the client because the client is the one who decides what ‘party-ready’ means. Playlist itself does not see that constant.

2. Suppose a teammate proposes a smaller fix for the Step 1 WatchHistory leak: keep storage as list[dict], but have recent() return tuple(self._history) (an immutable copy). They argue: “Now nobody can mutate it — the secret is hidden.” Are they right, in Parnas’s sense?

• Yes — fields are private and the return is immutable, so nothing leaks.

  A real improvement, but only for mutation leaks. Clients can still write code that depends on the shape of each element. Changing the element type still ripples.

• Not necessarily — the element type is still part of the contract.
• Yes — immutability is the entire point of information hiding.

  Immutability prevents accidental mutation. Information hiding is the broader discipline of choosing which design decisions clients may depend on. Element shape is one of those decisions.

• No — Python tuples are not really immutable; you can still mutate them with __setitem__.

  Python tuples are immutable in the sense that matters here — t[0] = ... raises TypeError, and tuple has no __setitem__. But this isn’t the issue with the design.

3. (Select all that apply.) Which of these future changes can your refactored Playlist absorb without forcing any change in app.py? (select all that apply)

• Switching internal storage from a list to a dict keyed by title.
• Adding a new field release_year to Track (the dataclass).

  Adding an optional field with a default value is absorbed; clients ignore it. But if you give it no default, callers of Track(...) must pass it — and Playlist.add calls Track(...). So it’s a ‘sometimes yes, sometimes no’ — we’ve marked it as optional credit.

• Adding a new domain method remove(title) to Playlist.
• Renaming the public method top_tracks to most_popular.

  Renaming a public method on Playlist by definition breaks every client that calls it. That is the opposite of an absorbed change — you have changed the contract.

4. You read a teammate’s class and the only thing wrong is that it exposes get_internal_list() -> list[dict]. They argue: “It’s only used by one client right now, so it can’t be a leak.” What is the strongest single counter?

• The method’s name uses the word internal, so it’s a smell.

  Naming is a hint, not the argument. A method called current_track() could leak just as badly.

• The cost shows up when the storage decision changes — every client written by then is also coupled.
• Returning a list is always wrong in Python; tuples are required by best practice.

  Lists are fine to return; the question is whether the return type is a leak. Often tuple[DomainObject, ...] is the safer shape, but not always.

• Information hiding requires zero exposed methods. Even get_internal_list() is too many.

  Information hiding never says ‘expose nothing’. It says ‘expose only the stable contract’. Plenty of legitimate methods exist.

5. Spaced retrieval from Step 1. Your Playlist._tracks is named with one underscore. Does the underscore alone hide the storage decision from app.py?

• Yes — Python respects the underscore convention strictly.

  Linters and IDEs respect the convention, but it is exactly that — a convention. It does not ‘hide’ anything by itself.

• Yes — once a field is _-prefixed, no outside code can read it.

  Outside code can still write playlist._tracks and Python will not raise. The convention is social, not enforced.

• No — the hiding comes from no public method returning or accepting the list.
• No — only __double_underscore names are truly private in Python.

  Even __double_underscore names are reachable via obj._ClassName__name (name mangling, not access control). The real hiding always comes from what the public API does or does not expose.

1. Why does summary(DictBackedPlaylist()) work even though DictBackedPlaylist does not have (PlaylistLike) in its class definition?

• Python silently injects PlaylistLike as a base class at runtime.

  Python doesn’t inject anything — inheritance has to be declared explicitly. Structural matching is a separate mechanism added by PEP 544.

• Protocol uses structural matching — any class with the required methods qualifies.
• DictBackedPlaylist inherits from Playlist, and Playlist is a PlaylistLike.

  Look at the file — there is no inheritance between them. Each class defines its own methods independently. Their being interchangeable does not come from a shared base class.

• Python ignores type annotations entirely at runtime, so the annotation is decorative.

  Half-right that Python ignores annotations at runtime — but mypy and Pyright don’t. And the Protocol mechanism is specifically designed for static checkers to enforce structural rules. ‘Annotations are decorative’ isn’t the reason the swap works — the structural rule is.

2. Spaced retrieval — Step 2. Now that PlaylistLike is declared, what — in Parnas’s sense — is the secret that PlaylistLike allows implementations to keep?

• How many tracks are in the playlist.

  That count is part of the contract — __len__ exposes it. The secret is what the contract doesn’t say.

• How tracks are stored — list vs. dict vs. anything else.
• Whether Python uses duck typing or static typing.

  That is a language-implementation detail, not a design decision the module owns.

• The fact that PlaylistLike is a Protocol.

  Being a Protocol is the mechanism. The secret is what the Protocol allows the implementer to keep private.

3. (Select all that apply.) Which of these classes would satisfy class CounterLike(Protocol) with def increment(self) -> None: ... and def value(self) -> int: ...? (select all that apply)

• class Tally: def increment(self): self.n += 1 def value(self): return self.n
• class Total(CounterLike): def increment(self): ... (no value defined)

  Inheriting from CounterLike doesn’t help — structural matching means the methods must actually exist on the class. Missing value ⇒ doesn’t satisfy. Inheritance without conformance is the worst of both worlds.

• class HiddenCount: def increment(self): self._n += 1 def value(self): return self._n
• class Logger: def log(self, msg): print(msg)

  Different methods entirely. The Protocol asks for increment and value; this class has neither.

4. Spaced retrieval — Step 1. A teammate writes class Wallet(Protocol) with one method def balance(self) -> int: ... and a concrete class CryptoWallet that has matching methods plus a public transactions: list[dict] attribute. They say “the Protocol hides the implementation.” Is that true?

• Yes — Protocols hide everything that isn’t declared in them.

  A Protocol describes a stable surface; it doesn’t prevent a concrete class from having a wider public API. Step 1’s lesson holds: hiding is about what the implementation chooses not to expose, not what the Protocol declares.

• No — transactions is still reachable on the concrete class.
• Yes — Python’s annotations enforce that only Protocol methods are visible.

  Python’s annotations are advisory at runtime. They guide type checkers; they don’t restrict attribute access.

• No — Protocols only work for read-only objects.

  There is no such restriction. Protocols can declare mutating methods too.

1. Parnas’s 1972 paper pointed out that even his “good” KWIC decomposition had a leak: the circular-shift module exposed an ordering its clients did not need. Which best matches the same leak in this step’s original recommend() function?

• The fact that recommend is a free function instead of a method on a class.

  Free vs. method is style. The leak is structural — what the contract says.

• The exposure of the raw score and its 0..30 scale, which locks in BM25-shaped scoring.
• The fact that recommend returns more than one hit at a time.

  Returning many hits is exactly what the client needs. Not a leak.

• The use of tuples instead of dicts as the return type.

  Tuples vs. dicts is a shape choice; both can be over-specified. The deeper leak is the score scale, which would also leak whether you wrapped it in a dict.

2. (Select all that apply.) Which of these are legitimate facts for the contract to promise to clients, and which would be leaks? Mark all the items that are LEAKS the contract should hide. (select all that apply)

• Each hit’s confidence is one of three labels: low, medium, or high.

  Legitimate. The Confidence enum is part of the stable contract — clients need it to filter.

• Hits are returned in descending confidence order (high before medium before low).

  Legitimate. Ordering by confidence is a domain promise the client genuinely needs. Note we don’t promise the secondary ordering within a confidence band — that lets the implementation tie-break however it wants.

• The exact numeric BM25 score for each hit.
• The internal bucket_id used to partition the search index.
• The query string can be empty (returns empty list).

  Legitimate. Edge-case behavior on empty input is part of the contract.

3. Spaced retrieval from Step 2. Suppose your PopularityRecommender internally stores its catalog as a list[tuple]. Which class is responsible for the decision “use a list of tuples”?

• sidebar.py — it consumes the data, so the storage is its responsibility.

  The client never sees the storage. If you made the client responsible, you’d be back in Step 1’s leak.

• Recommender — the Protocol owns all algorithmic decisions.

  A Protocol describes the contract, not the storage. It cannot ‘own’ a storage choice.

• PopularityRecommender — it is the one implementation that makes this storage choice, behind the shared contract.
• Both PopularityRecommender and EmbeddingRecommender — implementations of the same Protocol must agree on storage.

  The whole point of the Protocol is that each implementation makes its own storage choice. EmbeddingRecommender might use a NumPy array; PopularityRecommender might use a list. They never compare notes.

4. You’re reviewing a teammate’s PR. They added a new method to Recommender: def raw_score(self, hit: SongHit) -> float. Should you approve?

• Yes — extra methods are additive, so they can’t break clients.

  Additive changes are usually safe. This one isn’t, because it re-adds the very decision we worked to hide. Now EmbeddingRecommender must also expose a ‘score’ — even though embeddings don’t have a meaningful single score in the same scale.

• No — it puts the raw score back in the contract, re-leaking the decision.
• Yes, if they add a docstring saying clients shouldn’t use it.

  ‘Please don’t use this method’ is documentation as a substitute for hiding. It always loses to the next intern who really needs that number.

• Yes, if they mark it as a static method.

  Static vs. instance doesn’t affect contract leakage. The method is still on the Protocol.

5. Spaced retrieval — Step 3 (Protocol mechanics). Your PopularityRecommender was defined before Recommender(Protocol) appeared in the same file. A second class, EmbeddingRecommender, is defined in a test file — not even imported by recommender.py. Both satisfy the Recommender Protocol. Why does that work?

• Python silently rewrites both classes at import time to inherit from Recommender.

  Python doesn’t rewrite anything. There is no runtime injection of base classes.

• Structural subtyping — any class with matching methods qualifies.
• Only the second class works; the first one was defined before Recommender, so it can’t satisfy it.

  Definition order doesn’t matter for structural matching. A class satisfies a Protocol when its shape matches — when it was defined relative to the Protocol is irrelevant.

• It works because both classes happen to have recommend in their name.

  Method names matter — recommend matching is part of the structural match — but it’s the signature and existence that count, not the class name.

1. After the refactor, which of these changes touches only one file (the file that owns the storage secret)?

• Switching the production catalog from SQLite to a remote HTTP service.
• Renaming the ticket_price_cents field on Event to cents.

  Renaming a field on Event is a contract change — Event is shared by every client and every implementation. That ripples.

• Changing affordable_shows to return JSON instead of Event objects.

  affordable_shows returns to its caller. Changing the return type changes that contract.

• Adding a new field age_restriction to Event.

  Adding a field touches Event (contract) AND every implementation that constructs Events (every directory). That’s 2+ files.

2. (Select all that apply.) Which of these are good reasons your InMemoryEventDirectory is worth writing, even though production uses SQLite? (select all that apply)

• Tests don’t need a real database — they construct events in Python and run instantly.
• Two engineers can work in parallel: one builds the SQLite implementation, one builds the client features, both against InMemoryEventDirectory.
• Future readers see two implementations and learn the Protocol is what the contract really is — not whatever SQLite happens to do.
• It lets you ship the product to customers who don’t have SQLite installed.

  SQLite ships with Python’s standard library — no install needed. This isn’t a real win and you shouldn’t reach for it as the justification. The other three reasons are the real ones.

3. A teammate writes a new client function that takes an EventDirectory parameter. But for “convenience,” they also add a second parameter connection: sqlite3.Connection, because they need to do a one-off transaction-level operation. What is the problem?

• Two parameters is too many; pick one.

  Two parameters is fine. The number isn’t the issue.

• It re-introduces the sqlite3 coupling the Protocol was meant to remove.
• Nothing — EventDirectory is just an interface, you can take other parameters too.

  It IS a Protocol you can take other parameters alongside — but if the other parameter re-introduces the very coupling the Protocol was meant to remove, you have undone the abstraction.

• You shouldn’t use sqlite3 in Python; use SQLAlchemy.

  The library choice isn’t what’s at stake. Even an SQLAlchemy session parameter would re-couple the same way.

4. Spaced retrieval — Step 4 (overspecification). Your EventDirectory.find_in(city) returns list[Event]. The team is asked to add pagination. Two design proposals:

• A: find_in(self, city: str, *, page: int, page_size: int) -> list[Event]
• B: find_in(self, city: str, *, cursor: str | None = None, limit: int = 50) -> EventPage where EventPage is @dataclass(frozen=True) with events: list[Event] and next_cursor: str | None.

• A — page numbers are universal and familiar.

  Page numbers are familiar but they’re an implementation detail. They imply numeric offset and stable ordering between calls — two assumptions that break the moment the directory is backed by an event stream or a sharded service.

• B — cursors hide whether pagination is offset-, keyset-, or token-based.
• Neither — they hide the same amount of implementation detail.

  They look similar but B abstracts more: any pagination strategy can return some opaque cursor; only offset pagination can return a page number.

• A — EventPage adds a useless extra class for no gain.

  Wrapping the result in a small dataclass costs almost nothing and lets you evolve the response shape without breaking callers. (Useless? Add total_known: int later and no caller breaks.)

5. Spaced retrieval — Step 2 (representation). Your Event dataclass is declared @dataclass(frozen=True). Why frozen, specifically, and not just @dataclass?

• Frozen dataclasses are faster at construction.

  Performance is not the reason — at the per-instance scale you’d notice, cost is dominated by allocation, not field assignment. The reason to choose frozen is semantic (mutation safety).

• Callers can’t mutate an Event they received from find_in().
• Frozen is required for dataclasses to work with Protocol.

  Frozen and Protocol are independent features. A non-frozen dataclass still satisfies a Protocol if the methods match.

• Frozen automatically makes all fields private.

  Frozen has nothing to do with field privacy. All dataclass fields are public regardless of frozenness.

1. The Single Choice principle says: if a system supports several alternatives, only one module should know the exhaustive list. In your refactored code, where does the list of supported providers actually live?

• Inside play_track, share_track, and like_track — they each list which providers they support.

  That’s where it lived before the refactor. The three functions are now provider-agnostic. They never list providers.

• Inside the StreamingProvider Protocol — it lists all valid implementers.

  A Protocol describes the shape providers must satisfy. It doesn’t list which providers exist — that’s a runtime, not a type, concern.

• In the wiring code (composition root) that constructs the provider and hands it to the client functions.
• Nowhere — Python’s duck typing means no module knows.

  Duck typing tells you how the dispatch happens. The list of supported providers still has to be assembled somewhere — at the wiring layer. The win is that the list is in one place.

2. Before the refactor, the same if provider == "spotify": ... elif "apple_music" ... ladder appeared in three functions. What kind of coupling connected those three functions?

• Syntactic coupling — they all imported the same module.

  They all lived in the same file but didn’t import each other. The coupling was deeper than syntax.

• Semantic coupling — all three shared an assumption about the provider list.
• Inheritance coupling — they all derived from a common base.

  They were functions, not classes. No inheritance involved.

• There was no coupling — three separate functions are independent.

  They were dangerously coupled — through a shared assumption, not through a call. That’s the worst kind: invisible until something silently breaks.

3. (Select all that apply.) Which of these is now CHEAP to do, after your Single Choice refactor? (select all that apply)

• Add a fourth provider, e.g. YouTube Music — one new class, no edits to play_track/share_track/like_track.
• A/B-test two implementations of the Spotify provider at the same time (e.g., legacy SDK vs. new SDK) by passing different SpotifyProvider instances to different users.
• Drop one provider entirely (e.g. drop Tidal): delete the TidalProvider class and remove it from the wiring map.
• Rename the method like to favorite across all providers — that’s one keyword change in one file.

  Renaming a method on the Protocol is a contract change — every implementation must update, and every caller of provider.like(...) must update. That ripples. It’s the same lesson as Step 2’s quiz: renaming a public method on the contract is the opposite of an absorbed change.

4. Spaced retrieval — Step 1 (private isn’t enough). A teammate asks: “Could we have solved the original provider-coupling problem just by making provider a private field on a single shared module, instead of three top-level functions?” What’s the cleanest objection?

• Private fields would make the code uncompilable in Python.

  Python compiles fine with private (or even pseudo-private) attributes.

• No — the if/elif ladder would still appear in every method.
• Single Choice requires every variable to be public.

  Single Choice says nothing about field visibility — it’s about where the list of alternatives lives.

• Private fields are inherently slower at runtime.

  Speed is irrelevant to the question.

5. Spaced retrieval across the tutorial. Which of the following best describes the single common move that connects Steps 2, 4, 5, and 6?

• Add a @dataclass(frozen=True) to every input the SUT receives.

  Frozen dataclasses are a tool you used in three of the four refactors — for domain objects. Not for every input. Hashing the tool to the goal loses the point.

• Wrap each free function in a class with a single run() method.

  Wrapping things in classes was the visible artifact. The principle was always ‘hide the volatile decision’, not ‘wrap in class’.

• Replace direct exposure of a volatile decision with a stable contract.
• Add type hints to every parameter so the linter can find leaks.

  Type hints helped the linter and the reader. They didn’t hide anything by themselves.

1. Snippet 1.

class ConcertCalendar:
    def __init__(self):
        self._dates: list[dict] = []
    def add(self, date_iso: str, venue: str):
        self._dates.append({"date": date_iso, "venue": venue})
    def all(self) -> list[dict]:
        return self._dates

• Representation leak — clients can mutate the internal list and depend on its keys.
• Over-specification leak — the contract reveals a scoring/ordering detail.

  There’s no algorithmic ordering being revealed — no scores, no scale. The leak is shape, not algorithm.

• Persistence leak — a storage technology is exposed in the contract.

  No storage technology mentioned. The list is in-memory and an implementation detail. The leak is shape, not persistence.

• Exhaustive-alternatives leak — an if x == ladder appears in multiple places.

  No exhaustive list of alternatives appears.

• Not a leak — this contract is fine.

  Returning the internal list[dict] by reference is the exact anti-pattern Step 2 refuted (and Step 1’s WatchHistory.recent() before it). Clients can mutate it and depend on dict keys. That’s a leak.

2. Snippet 2.

def rank_articles(query: str) -> list[tuple[int, float, dict]]:
    """Returns (shard_id, tfidf_score, raw_row) tuples."""
    ...

• Representation leak — list and dict show internal storage.

  Yes the return type uses list and dict — but the deeper problem is what those values mean: tfidf_score and its scale lock the contract to one algorithm. The shape is a symptom; the algorithm leak is the root.

• Over-specification leak — the contract names the score scale and algorithm.
• Persistence leak — a database schema is exposed.

  No database object is in the signature.

• Exhaustive-alternatives leak — a list of providers is repeated.

  No ladder of alternatives appears.

• Not a leak — the contract is precise, which is good.

  Precision and over-specification are different things. The contract specifies more than the client needs — the score scale and shard_id are implementation choices, not domain concepts. Step 4’s exact lesson.

3. Snippet 3.

def list_attendees(
    conn: sqlite3.Connection,
    table: str,
    event_id: int,
) -> list[dict]:
    return conn.execute(
        f"SELECT name, email FROM {table} WHERE event_id = ?",
        (event_id,),
    ).fetchall()

• Representation leak — list[dict] exposes element shape.

  list[dict] is a secondary issue — fixing it without fixing the Connection parameter still leaves you tied to SQLite. The deeper leak is which storage technology is named in the signature.

• Over-specification leak — event_id: int ties clients to integer IDs.

  Integer IDs are usually a fine domain primitive. They’re not the leak here.

• Persistence leak — the signature names sqlite3.Connection and a SQL table.
• Exhaustive-alternatives leak — multiple event types are switched on.

  No alternatives ladder; this is a single function.

• Not a leak — type hints make this safe.

  Type hints describe shape; a sqlite3.Connection parameter is the leak the type hint names. Step 5’s lesson exactly — annotations don’t hide what they name.

4. Snippet 4.

def send_notification(channel: str, recipient: str, body: str) -> None:
    if channel == "email":
        send_email(recipient, body)
    elif channel == "sms":
        send_sms(recipient, body)
    elif channel == "push":
        send_push(recipient, body)
    else:
        raise ValueError(channel)

def queue_notification(channel: str, recipient: str, body: str) -> str:
    if channel == "email":
        return f"queued email job to {recipient}"
    elif channel == "sms":
        return f"queued sms job to {recipient}"
    elif channel == "push":
        return f"queued push job to {recipient}"
    else:
        raise ValueError(channel)

• Representation leak — str exposes the channel identifier.

  Strings as IDs are fine; that’s not the leak. The leak is repetition of the same allowed-strings list.

• Over-specification leak — channel choice reveals delivery strategy.

  The channels (email/sms/push) are the domain concepts at this layer — a UI must show which ones exist. The leak is that the list is repeated, not that it’s visible.

• Persistence leak — queue_notification mentions a queue.

  The word ‘queue’ is a domain concept here, not a storage technology.

• Exhaustive-alternatives leak — the channel list is repeated in two functions.
• Not a leak — clear if/elif is good practice.

  Repeating the same if x == ladder in multiple functions is the exact Single Choice violation Step 6 refuted. Adding a fourth channel requires editing both functions; missing either ships a half-broken feature.

5. Snippet 5 — the honest one.

# cleanup_old_drafts.py
# Run weekly via cron. Deletes draft files older than 30 days.

import time
from pathlib import Path

DRAFT_DIR = Path("/var/app/drafts")
CUTOFF_SECONDS = 30 * 24 * 3600

for path in DRAFT_DIR.glob("*.draft"):
    if time.time() - path.stat().st_mtime > CUTOFF_SECONDS:
        path.unlink()

• Yes — every filesystem operation should be hidden behind a Protocol.

  Information hiding is a bet on future change. A 10-line script with no other callers is the wrong place to bet. The chapter’s ‘When NOT to apply’ section exists for exactly this reason.

• No — a 10-line cron script with no second caller doesn’t earn the indirection.
• Yes — Step 5 said to always hide persistence.

  Step 5 said to hide persistence when the future change is plausible — production catalogs with multiple readers, yes; a 10-line cron job with no second caller, no. Always-hide is the over-application failure mode this step calibrates against.

• No — but only because Python’s pathlib is already an abstraction.

  pathlib.Path is a thin wrapper around filesystem syscalls; it doesn’t hide which filesystem you’re touching. The reason to skip the abstraction is the script’s small scope, not pathlib’s design.

6. Snippet 6 — interleaved final.

# tournament.py
class TournamentBracket:
    def __init__(self):
        self._matches: list[dict] = []
    def add_match(self, team_a: str, team_b: str, court: str):
        self._matches.append({"a": team_a, "b": team_b, "court": court})

    def assign_court(self, match_index: int, court_provider: str) -> str:
        if court_provider == "stadium":
            return f"Stadium court for match {match_index}"
        elif court_provider == "outdoor":
            return f"Outdoor court for match {match_index}"
        elif court_provider == "indoor":
            return f"Indoor court for match {match_index}"
        raise ValueError(court_provider)

    def matches(self) -> list[dict]:
        return self._matches

• Representation leak — matches() returns the internal list[dict] by reference.
• Over-specification leak — assign_court reveals a score scale.

  No score or numeric scale is exposed. The leaks are shape and exhaustive-list — not algorithmic.

• Persistence leak — a database is exposed.

  No storage technology appears.

• Exhaustive-alternatives leak — assign_court enumerates the court-provider list inline.

1. Change 1: Add YouTube Music as a fourth streaming service. Users should be able to play, share, and like tracks on it just like the other three. Which files need to be edited? (Select all that apply.) (select all that apply)

• streaming.py — add a YouTubeMusicProvider class implementing the Protocol.
• composition_root.py — add "youtube_music": YouTubeMusicProvider to the wiring registry.
• ui.py — add a branch for the new provider in /share and /like handlers.

  If ui.py needed a branch for each provider, you’d be back in the same Single Choice violation Step 6 was about. The whole point of polymorphism behind the StreamingProvider Protocol is that ui.py calls provider.play(...) without caring which provider it is.

• playlist.py — playlists need to track which provider each track came from.

  Tempting because YouTube Music tracks feel different, but the Track dataclass already has all the fields it needs. Provider is a concern of streaming.py, not playlist.py.

2. Change 2: The SRE team migrates the production concert catalog from SQLite to a remote HTTP service (an internal REST API). The data shape is the same; only the storage moves. Which files need to be edited? (Select all that apply.) (select all that apply)

• events.py — add an HttpEventDirectory class implementing the EventDirectory Protocol.
• composition_root.py — swap in HttpEventDirectory(...) when constructing the directory.
• ui.py — change the /concerts/<city> handler to make HTTP requests instead of database queries.

  ui.py only knows the EventDirectory Protocol — it calls directory.find_in(city). The storage technology is hidden from it, by design.

• Every test that builds an in-memory event directory — they all need to add an HTTP mock.

  Tests that build InMemoryEventDirectory are unaffected. That’s exactly why you wrote that in-memory class in Step 5 — fast, hermetic tests that don’t care which production backend the app uses today.

3. Change 3: Product wants the UI to show “about 3 minutes” instead of “194 seconds” everywhere a track duration appears. A new humanized-duration string is needed on each Track. Which files need to be edited? (Select all that apply.) (select all that apply)

• playlist.py — add a humanized_duration property to Track, or a helper next to the data.
• ui.py — call the new property/helper where tracks render.
• recommender.py — Recommender returns song data, so it should carry the new humanized duration too.

  Tempting because the recommender returns song info — but check SongHit’s actual fields: track_id, title, artist, confidence. No duration_sec. The new humanized field isn’t part of this contract, so the file doesn’t need editing. Read the actual contract before predicting impact.

• streaming.py — StreamingProvider.play() should report the duration as part of its confirmation message.

  Tempting because the streaming provider plays tracks — but check what play() actually returns: a confirmation string, not a duration. The humanized field doesn’t belong in streaming.py’s contract.

4. Change 4 — the “don’t refactor” calibration. A new teammate proposes: “I want to write a one-off script, nightly_health_check.py, that connects directly to SQLite and prints a count of events per city to a log file. It runs once a night via cron, doesn’t share code with anything else, and the whole thing is ~25 lines.” They ask: “Should I make it use the EventDirectory Protocol instead of sqlite3 directly?” What is the right call?

• Yes — every SQLite usage in the codebase should go through EventDirectory.

  Information hiding is a bet on future change. The bet’s cost is the layer of indirection every reader pays. For a 25-line one-off script, that cost is paid forever with no payoff. Step 7’s Snippet 5 was exactly this lesson.

• No — a 25-line cron script with no second caller doesn’t earn the indirection.
• Yes — Step 5 said to always hide persistence behind a Protocol.

  Step 5 said to hide persistence when the change is plausible — production catalogs with many readers, yes; one-off scripts, no. Always-hide is the over-application failure mode you trained against in Step 7.

• No — nightly_health_check.py should use a completely different ORM to be safe.

  Switching ORMs adds more coupling, not less, and doesn’t address the question. The honest answer is: this script doesn’t need an abstraction layer at all.

5. The honest tradeoff. Tempero, Blincoe, and Lottridge (2023) found that more modular code helped students complete modification tasks but did not consistently make code easier to understand on first encounter. What is the right takeaway?

• Modularity is overrated; skip it.

  The study showed modularity helps modification — the very task most engineers spend most of their time on. Skipping it is the wrong call.

• Apply information hiding aggressively everywhere, including throwaway scripts and one-off demos.

  Aggressive hiding adds layers without payoff in places where the decision will never change. That’s the trap this option warns against, and the exact lesson of Step 7’s Snippet 5 and Change 4 above.

• Apply hiding where future change is plausible — the payoff is in maintenance, not first-read clarity.
• Hide everything — every method should be private, every class should have a Protocol.

  ‘Hide everything’ is the over-applied version of the principle that the chapter’s When NOT to apply section warns about. Indirection has a real reading cost. Pay it where change is plausible; skip it where it isn’t.

6. Cold transfer — no MusicShare scaffolding this time. CampusRide has these modules:

• scooters.py owns a ScooterGateway(Protocol) with nearby(location) and reserve(scooter_id).
• trip_planner.py chooses a route from available scooters and campus buildings.
• pricing.py computes student discounts and surge pricing.
• ui.py renders the map and reservation button.
• composition_root.py wires today’s concrete gateway into the app.

• scooters.py — add or replace the concrete gateway implementation that knows the vendor protocol.
• composition_root.py — wire the app to the new concrete gateway.
• trip_planner.py — route choice must change because GraphQL is a different query language.

  trip_planner.py depends on domain scooter data, not the vendor wire protocol. If it must change for REST -> GraphQL, the gateway leaked.

• pricing.py — student discounts must change because vendor transport changed.

  Pricing policy is a separate secret. A vendor transport change should not rewrite discount rules.

• ui.py — the map must render GraphQL responses directly.

  ui.py should render domain objects from the gateway, not raw vendor responses. Rendering GraphQL payloads directly would be the same leak you fixed in Steps 4 and 5.