The big idea: Object-oriented programming keeps a thing's data and the operations on it in one place.
A book's title and its borrow() method live together, rather than the data sitting in one list and the code that handles it in another.
A Book class, the objects made from it, static variables and encapsulation. Step through all four.
Interactive diagram
Explore the labelled diagram, charts and maps for this topic in full study mode.
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.
Class — the template
Object — one actual thing
Encapsulation — private data, public methods
Inheritance — a more specific kind
Polymorphism — same call, right behaviour
The two that get confused: Inheritance is about reusing what a more general class already has.
Polymorphism is about calling the same method on different kinds and each responding properly. Inheritance is often how polymorphism becomes possible, but they are not the same idea.
Feeling unprepared for exams?
Get a clear study plan, practice with real questions, and know exactly where you stand before exam day. No more guessing.
What OOP gives you
- Models the real world — a Book object behaves like a book
- Reuse through inheritance, with no copied code to drift apart
- Encapsulation means invalid states can be refused at the door
- Large programs split into parts people can work on separately
- Easier to extend: a new kind of Book needs no change to existing code
What it costs
- More to design — classes and relationships must be worked out first
- Deep inheritance chains become hard to follow
- More code for a small task: a script does not need classes
- A small overhead in memory and speed
- Poor class design is harder to fix than poor procedural code
When it earns its place: OOP pays when there are real things with both data and behaviour, when a program is large or long-lived, or when several people work on it.
For a fifty-line script that reads a file and prints a total, it is overhead with no return.
How this is tested — you must EVALUATE — weigh what OOP gives against what it costs, for this scenario. It comes up two ways:
Paper 2 — working with code
- Evaluate the use of OOP, 4-6 marks
- Define and illustrate the five concepts
- Say whether OOP suits a described program
Paper 2 — the algorithmic-thinking question
- Decide from a description with no code shown
- Justify the choice from the program's size and lifetime
The classic trap: Listing advantages only. Evaluate requires the costs too — the design effort, the extra code, and the fact that a small script gains nothing from any of it.
A school is building a library system handling books, ebooks, members and loans, to be maintained for many years. Evaluate the use of OOP.
Model answer plan
See the mark-by-mark plan — for / against / judgement, with marking guidance — in study mode.