Abstraction: A Useful Interface and Contract
Ask for a result without repeating every internal step
Several reports need to know whether a student passed. They should not each hard-code the school threshold; one well-named operation can express that decision.
An abstraction exposes the useful operation and contract while letting callers ignore implementation details they do not need. It hides details, not responsibility for correctness.
Describe a contract
State valid inputs and the meaning of the result.
Use an interface
Call a pass rule without duplicating its threshold.
Recognize leaks
Explain when hidden costs or exceptions still affect callers.
A caller uses the contract
Input
Supply a validated numeric mark.
35Shared operation
Apply the school pass policy internally.
passed(mark)Result
Return a boolean for the caller to use.
true
A good name expresses what, not an incidental implementation
passed(mark) describes a question. Its contract says it accepts a validated mark and returns whether the school’s pass threshold is met. Callers need that meaning, not a copy of the comparison.
Encapsulation controls access to internal state. Abstraction helps callers reason through an interface. A function can provide an abstraction without owning private mutable state or being part of a class.
Before starting, review reusable named functions. These examples use JavaScript; other languages can use different syntax and rules.
Use one rule in two reports
The function returns true for 35 and false for 20 using a shared threshold. Callers receive booleans rather than needing to know how the comparison is written.
If the policy changes, one authoritative implementation can be updated. Its promised meaning must still be clear to callers.
JavaScript · local teaching example
function passed(mark) {
return mark >= 25;
}
console.log(passed(35));
console.log(passed(20));Expected output
true
falseBuild a report from a smaller operation
The report function uses the boolean operation and chooses text. The conditional operator ? : selects a result based on that boolean.
Keeping the pass calculation separate lets another caller use it without being forced to display the same message.
JavaScript · local teaching example
function passed(mark) { return mark >= 25; }
function feedback(mark) {
return passed(mark) ? 'Passed' : 'Try again';
}
console.log(feedback(35));Expected output
PassedApply the rule to a small change
Write an abstraction for “excellent,” with a threshold of 40, and test marks 39 and 40.
Worked answer
The boundary is inclusive. The two results are false and true. Choosing the name excellent makes the policy question visible to callers.
JavaScript · local teaching example
function excellent(mark) {
return mark >= 40;
}
console.log(excellent(39));
console.log(excellent(40));Expected output
false
trueRecognize mistakes and limits
An abstraction should not hide important behavior such as network delays, possible errors or destructive writes. Callers still need enough information to use it safely and efficiently.
A misleading name can conceal mistakes. If the operation requires validated input, document where validation happens; do not imply a comparison alone verifies every mark. Add abstraction where it removes repeated reasoning rather than just renaming one arbitrary line.
For the language or tool rules used here, see JavaScript class behavior.
Check the core idea
Apply the idea to a new situation
Hide details while keeping promises visible
Abstraction lets callers work with meaning and a contract. Encapsulation addresses state boundaries. Neither removes the need to document important costs, errors and validation assumptions.
Connect this idea with shared rules and focused responsibilities.
Reaching the recap and completing the quizzes are separate milestones.