C42 · Topic 3.13 · 40 minutes · AAP-3.B, AAP-3.C
Explaining procedural abstraction
By the end you can:
- Explain a concrete benefit of one shared definition.
- Use existing behaviour through appropriate arguments.
- Recognise limits of reuse.
Before this lesson: topics 3.8, 3.10, 3.12.
- Procedural abstraction
- Using a named procedure through its purpose/interface while hiding implementation details.
- Generalisation
- Replacing fixed choices with meaningful parameters so one definition serves multiple cases.
Understand
Procedural abstraction lets callers express what they need at a higher level without repeating every implementation step. If multiple callers use one correct definition, a repair to that shared implementation applies to them. Copied code can drift when only one copy receives the fix.
A generalisation should preserve useful existing behaviour through suitable arguments. Reuse is not a guarantee of correctness: the shared contract must fit each caller, relevant parameters must be used and tests must cover the callers’ cases. Explain a specific reduction in duplicated code or changes rather than only saying the procedure is convenient.
Worked example
One page recommends capacities 5…8 and another 8…10 using the same recommend procedure.
- Each page supplies its own bounds rather than copying the traversal.
- Correcting an accidental strict upper comparison in the shared body repairs both callers.
- A caller needing a sorted result must still check the contract: this procedure preserves input order and does not promise sorting.
Explore each concept
Choose a concept, change its inputs and follow the explanation. Each example models the stated rule or scenario; completing it is practice rather than evidence of mastery.
- One shared definition
- Modularity
- Ignored parameters and compatible calls
Change it · step through · explain
Change an input, predict what will happen, then advance one step. Read why the state changes, reset and experiment. This fixed teaching model does not save progress or award XP.
Ready · Make a prediction
- First caller threshold (0–10)3Waiting
- Second caller threshold (0–10)5Waiting
- ImplementationsharedWaiting
Ready to explore: Refactor copies and test meaningful parameters
Why: Change an input, predict the first effect, then advance one step.
Try this: Change one input or choose another listed case. Predict the effect, reset and compare the states and governing rule.
Step through and experiment
Change it · step through · explain
Change an input, predict what will happen, then advance one step. Read why the state changes, reset and experiment. This fixed teaching model does not save progress or award XP.
Ready · Make a prediction
- Input 11,5,8,5,10Waiting
- Input 25Waiting
- Input 38Waiting
Ready to experiment
Why: Predict the first change, then advance one step.
Try this: Try repeated boundary values, no matches and an empty list.
Check a misconception
Claim: A shared procedure automatically meets every future requirement.
Its documented contract must fit the new use; reuse does not add unstated behaviour.
Guided practice
Explain the concrete maintenance benefit of this shared range filter.
Work with a partner. Make a prediction, compare your reasoning, then identify the rule that supports your answer.
Independent transfer
A previous procedure returned values at least 5 with no upper limit. Can a finite high always preserve that behaviour for arbitrary unbounded numbers?
Exit check
Why is a name alone insufficient evidence that abstraction manages complexity?
Write your reasoning before comparing with a classmate. If your teacher assigned this task, submit it through My classes to save your work and receive feedback.
Check yourself
Your practice so far
Check an answer to see its rationale.