The big idea: Abstraction means showing only the operations a user needs, and hiding how they are done.
A driver turns a key. Combustion, timing and fuel injection all happen — none of them are on the dashboard.
| Abstraction | Encapsulation | |
|---|---|---|
| Question answered | What should be visible? | How is it protected? |
| Concerned with | Design — the interface | Implementation — access control |
| Achieved by | Abstract classes, interfaces, method design | private, protected, getters and setters |
| Purpose | Reduce what a caller must understand | Stop invalid state being created |
Not the same thing, and routinely swapped: They work together, so answers blur them. Abstraction decides what the outside world should see. Encapsulation enforces it.
If a question asks for both, give the distinction above in one sentence each.
Free preview
This is the free notes preview
You're reading the free notes. Aimnova Pro unlocks the full study experience — and you can try it with your first topic free to keep:
- FlashcardsLock in vocabulary and key terms with spaced repetition.
- Practice questionsAnswer exam-style questions and get instant AI marking.
- Mock exams & past-paper vaultSit full mocks and see exactly how examiners award marks.
- Personalised study planA daily plan built around your exam date and weak areas.
Start Studying Free Full access to Aimnova Pro · cancel anytime
from abc import ABC, abstractmethod
class PaymentMethod(ABC):
@abstractmethod
def pay(self, amount): # no body — a requirement, not a behaviour
pass
def receipt(self, amount): # shared behaviour all children get
return f"Paid {amount:.2f}"
class Card(PaymentMethod):
def pay(self, amount):
return "charged to card"
# PaymentMethod() -> error: it is abstract, so it cannot be instantiatedabstract class PaymentMethod {
abstract String pay(double amount); // no body — a requirement, not a behaviour
String receipt(double amount) { // shared behaviour all children get
return String.format("Paid %.2f", amount);
}
}
class Card extends PaymentMethod {
@Override String pay(double amount) {
return "charged to card";
}
}
// new PaymentMethod() -> error: it is abstract, so it cannot be instantiatedAbstract class
- Cannot be instantiated — it describes a kind, not a thing
- May hold some implemented methods and shared attributes
- A child must implement every abstract method
- Use when children share real behaviour
Interface
- Only the signatures — a pure contract
- A class can implement many interfaces
- Use when unrelated classes must offer the same operations
- "Can-do" rather than "is-a"
What both give
- A guarantee that the method exists on every implementer
- Which is exactly what polymorphic code depends on
- Callers depend on the promise, never on any one class
Why abstract classes cannot be instantiated: An abstract method has no body. An object of that class could be asked to run a method that does not exist — so the language refuses to create one.
It is a promise about children, not a thing in its own right.
Know your predicted grade
Take timed mock exams and get detailed feedback on every answer. See exactly where you're losing marks.
Try Mock Exams FreeYour first topic is free to keep • No credit card required
What a good abstraction does
- Names operations in the caller's language — deposit(), not updateBalanceField()
- Leaves no way to reach a partially-updated state from outside
- Can be re-implemented completely with no caller changing
- Is small: every extra public method is a promise that must be kept forever
Abstraction makes code modular: Behind a fixed interface each class becomes a module: one programmer can write PaymentMethod's children while another writes the checkout that calls pay(), and either can be tested or replaced on its own.
The leak test: If a caller must know how something works to use it correctly, the abstraction has leaked.
A method called saveToMySQL() forces every caller to know the database. save() does not — and can be changed later without anyone noticing.
How this is tested — you must distinguish abstraction from encapsulation, and justify hiding something specific. It comes up two ways:
Paper 2 — working with code
- Explain abstraction, 3-4 marks
- Distinguish it from encapsulation
- State why an abstract class cannot be instantiated
Paper 2 — the algorithmic-thinking question
- Design an abstract class or interface for a scenario
- Explain what a change of implementation would cost
The classic trap: Answering "abstraction means hiding data". That is encapsulation. Abstraction is about what is exposed — the interface — not about access modifiers.
IB-style questionExplain[5 marks]
A weather app fetches data from an online service. Explain how an abstract WeatherSource class with a getForecast() method helps when the provider is changed.
Model answer plan
See the answer broken into clear points, with guidance on how each point earns marks.