Base CS from zero
Abstraction: multiple-choice review
Crux Multiple-choice synthesis across the abstraction unit — interface vs implementation, encapsulation, module boundaries, namespacing, and why every non-trivial abstraction leaks.
Your altitude — climbing toward senior
ZeroJuniorMiddleSenior
You are at middle altitude — in the skySix questions that cut across the whole unit. Each one is a judgement call a working programmer makes — not a definition to recite, but the line between what an abstraction promises and what it actually hides.
Goal
Confirm you can connect the four ideas the unit built toward — interface vs implementation, encapsulation in a bundle, the module boundary and namespacing, and the leaky-abstraction tradeoff — and apply them to code you have never seen before.
Quiz
Completed
A team rewrites the body of add(a, b) to compute the sum a faster way. The name, the two inputs, and the returned sum all stay the same. How many of the hundreds of call sites must change, and why?
Heads-up Callers depend on the interface, not the body. As long as the name, inputs, and result are unchanged, the body can be rewritten completely and no caller changes by one character.
Heads-up Callers cannot read a function's local variables at all — those are part of the hidden implementation. Nothing outside the body depends on them, so there is nothing to update.
Heads-up Rewriting the body is exactly what abstraction makes safe. The reason zero callers change is the fixed interface, not any rule against editing the body.
Quiz
Completed
A counter object bundles a data field count with methods increment() and value(). What does encapsulation actually buy you here?
Heads-up Encapsulation is about what is exposed versus hidden, not speed. A method is just a function stored as a field; bundling changes visibility and maintainability, not execution speed.
Heads-up That is the opposite of encapsulation. The whole point is that callers use the methods and never name the data field, so the layout stays hidden and changeable.
Heads-up count still exists and still holds the state — the methods read and write it through this. Encapsulation hides the field from outside code, it does not remove it.
Quiz
Completed
A module defines six names and marks two of them as exports. Outside code tries to call one of the four unexported names directly. What happens, and why was the boundary worth enforcing?
Heads-up By default a module's names are private — visible only inside it. Only the two exported names cross the boundary; the other four cannot be named from outside at all.
Heads-up Privacy does not depend on whether the name holds a function or a value. Any name not marked as an export is invisible across the boundary, function or not.
Heads-up It fails because the names are private, not because of any collision. Even with no name clash anywhere, an unexported name cannot be reached from outside.
Quiz
Completed
A large program needs two functions both sensibly called format — one for dates, one for currency. Why does putting each in its own module stop them from colliding?
Heads-up Nothing is silently renamed. The names stay format in each module; they do not clash because each is reached through its own module name, which gives it a separate home.
Heads-up Both can exist at once. Namespacing is precisely what lets identical short names coexist — each module is a fresh space, so neither has to be deleted.
Heads-up Modules keep the two functions entirely separate; they do not merge code. The boundary plus the module handle is what keeps the two format names apart.
Quiz
Completed
A function-call abstraction works fine for thousands of ordinary calls, then a runaway recursion crashes with a stack-overflow error that names stack frames. How should you read this through the unit?
Heads-up It worked correctly for thousands of calls — that is real value. The Law of Leaky Abstractions says all non-trivial abstractions leak to some degree; a leak does not make the abstraction useless.
Heads-up No abstraction over a real machine is leak-proof. Time, memory, and a finite stack are real properties of the layer below that no higher interface can fully hide.
Heads-up It hid the stack for every ordinary call — you wrote f() thousands of times without thinking about frames. It only surfaced when the lower layer failed, which is exactly what a leak is.
Quiz
Completed
Because every non-trivial abstraction leaks, a colleague concludes you should stop learning the layers underneath the ones you work in. What is wrong with that conclusion?
Heads-up The lower layer still runs and can still leak. An abstraction removes detail from your attention while things work; it does not free you from understanding the layer for when it breaks.
Heads-up Leaks are not exotic — they surface whenever the lower layer fails or runs slow, which happens routinely in real systems. That is precisely why the underlying layers must be learned.
Heads-up Abstraction is about managing complexity — what you must hold in mind — not raw speed. The flaw in the conclusion is that any layer can leak, so none can be safely ignored forever.
Recap
The unit’s through-line is one chain: an abstraction is a fixed interface over a hidden, replaceable implementation; a bundle applies that to data plus its operations and calls the hiding encapsulation; a module applies it to a whole group of code, with an enforced boundary and namespacing so private detail stays untouchable and short names stop colliding; and stacking these layers is how you manage complexity. The price is the leak — every non-trivial abstraction surfaces the layer below when that layer fails or runs slow, which is why you use the interface for the reasoning it buys and still learn the machinery underneath.