OOP Foundations & UML Class Design
Model a real-world problem with classes and objects, then turn requirements into an explicit class design.
What you need to be able to do
- evaluate OOP as a way to model real-world entities using classes, objects, inheritance, encapsulation and polymorphism;
- explain advantages and disadvantages of OOP in different programming scenarios;
- construct a class design from application requirements;
- use a UML class diagram to show a class name, attributes and methods, and recognize that UML can also show relationships between classes.
Rapid Recall Deck
Attempt each card first. If a term is new, flip and study it, then answer it again without looking. Mark only secure recall as “Know it”.
From a real entity to an OOP model
Choose the state
Which information belongs as attributes of a LibraryBook object?
Suitable attributes include title, author, available and borrower. Each object stores the state of one specific book.
Choose the behaviour
Which methods should the class provide so the requirements can be enforced?
Reasonable methods include borrow(student_name), which succeeds only if the book is available, and return_book(), which clears the borrower and restores availability.
Turn requirements into a class design
Read the UML
+---------------------------+ | LibraryBook | +---------------------------+ | title | | author | | available | | borrower | +---------------------------+ | borrow(student_name) | | return_book() | +---------------------------+
State what each compartment communicates to a programmer.
The top compartment names the class, the middle lists its attributes/state, and the bottom lists methods/behaviour.
Construct a UML design
A StudyRoom must store a room number, capacity and whether it is reserved. It must support reserve(), cancel() and can_fit(group_size). A separate Reservation class stores a student name and start time. Show an association between the two classes.
StudyRoom ---------------- room_number capacity reserved ---------------- reserve() cancel() can_fit(group_size) StudyRoom -------- Reservation Reservation ---------------- student_name start_time ----------------
Library class related to LibraryBook objects. Later lessons distinguish inheritance, aggregation and composition; here the key skill is recognizing that relationships can be part of the design as well as attributes and methods.OOP is useful, not automatically better
Evaluate OOP for both tasks
OOP is a strong fit for the school system because many related entities have persistent state and behaviour; classes can improve modularity, reuse and maintenance. For the five-line renaming script, class design may add unnecessary structure and make a simple procedural solution harder to read. The value of OOP therefore depends on problem complexity and expected growth.
Teacher-created Paper 2 practice
Paper 2 mini-set
1. A fitness app must store a workout’s name, duration and completion status and support complete() and summary(). Construct a UML class design.
2. Explain the difference between a class and an object using one example from the fitness app.
3. Evaluate one advantage and one disadvantage of using OOP for a system that will eventually contain workouts, users, coaches and subscriptions.
- UML should contain a suitable class name such as
Workout, attributesname,duration,completed, and methodscomplete(),summary(). - A class is the blueprint; an object is one concrete workout instance with actual attribute values.
- A strong evaluation links a benefit such as modularity/reuse/real-world modelling and a limitation such as design complexity/overhead to the growing multi-entity system.
Can you move from requirements to design?
Quick oral check
Explain aloud: why is “a class is an object” an incorrect statement?
A class defines the structure and behaviour. An object is one instance created from that class.
Design repair
A student puts borrower and borrow() outside the LibraryBook class even though both directly control a book’s state. Explain one reason to move them into the class.
Keeping related state and behaviour together improves cohesion and makes the rules controlling a book easier to maintain and reuse.
Finish the learning cycle
IA — main task
Continue Criterion D development. Add one short note explaining a class/design decision if OOP is relevant to your solution; do not force OOP if it is not appropriate.
Paper 2 — short practice
Redo the UML construction and OOP evaluation without revealing the model. Review only flashcards marked “Review again”.