HL OOP checkpoint · B3.2.1–B3.2.5
Additional challenges
Finished the HL OOP techniques? Explore a hierarchy, prototype one design pattern, model relationships or invent your own small system while other students finish or revisit the section. These are optional design exercises, not previews of the checkpoint exam.
Follow an interest
You can focus deeply on one part of HL OOP rather than forcing every concept into the same program.
Still catching up?
Return to inheritance, polymorphism, abstraction, relationships or patterns and secure the technique first.
Checkpoint exam
Your teacher gives the final controlled HL OOP assessment separately in class. It remains unseen on the site.
Challenges Choose one
Choose a challenge that feels appropriate for you. Code heat is only a rough estimate, not a fixed level.
Build a Hierarchy You Care About
SelectedChoose a genuine is-a hierarchy from something you know well: game enemies, dog breeds, vehicles, musical instruments, sports roles or another suitable domain. Design a general parent and at least two specialised child classes. Decide whether the parent should be concrete or abstract and justify that decision. Give the child classes different implementations of one shared behaviour, then process mixed child objects through the parent role so runtime polymorphism is visible without type-checking branches. Draw the UML with the hollow inheritance triangle pointing to the parent.
The domain is your choice. The important part is whether the hierarchy is genuinely defensible, not whether it matches somebody else's example.
Pattern Prototype
SelectedThink of a small recurring design problem in an app, game or system you understand. Decide whether Singleton, Factory or Observer is the best fit, then build the smallest prototype that demonstrates why. Keep the surrounding program deliberately tiny. Finish with a short explanation of the problem the pattern solves, one trade-off it introduces, and why one of the other two patterns would not solve the same problem as well.
Do not build three patterns. The challenge is choosing one for a reason.
Model the Relationships
SelectedChoose a small domain with several interacting objects: a game inventory, playlist, sports club, school event, café order, travel plan or something of your own. Design three to five classes and draw their UML relationships. Include a plain association where objects simply interact, and use aggregation or composition only where ownership and lifetime genuinely justify the diamond. Code a small slice of the model that demonstrates the relationships you chose, then explain one relationship that could reasonably be modelled differently in another system.
The goal is not to collect UML symbols. Every line or diamond needs a modelling reason.
Open HL OOP Build
SelectedDesign a small object-oriented program about something you care about. Choose at least three HL OOP ideas from inheritance, polymorphism, abstraction, composition/aggregation and design patterns, but use them only where they genuinely improve the model. Start with UML, keep the implementation small enough to finish, and end with a brief design explanation showing why each chosen idea belongs in your program.
This is the most independent option. A smaller coherent design using three ideas well is better than a large program that forces in every syllabus term.
Selected challenge
This choice is shared with the portfolio setup page.
Plan your solution in handwritten pseudocode
Before opening your IDE or writing any program code, handwrite pseudocode for this challenge on paper.
Not marked complete. If you submit now, the GitHub README will record “No”.
Create your challenge folder
Run this command after planning. It creates the correct empty folder inside your portfolio.
Complete the challenge
Use your handwritten pseudocode as the starting plan, then write and test your solution in the folder created above.
Optional two-level scaffold
Try from your handwritten pseudocode first. Scaffold gives some structure; Scaffold + comments gives stronger guidance. Use only the level you need, and update your pseudocode first if the support changes your plan.
Submit for review
Run this when your program is complete. It creates the README, commits the folder and pushes it. The README records whether you marked the handwritten pseudocode as complete; the paper itself is handed to your teacher separately.