SL OOP checkpoint · B3.1.1–B3.1.5
Additional challenges
Finished the shared OOP techniques? This is a chance to use classes for something you actually care about while other students finish or revisit the section. These are optional builds and explorations, not copies of the checkpoint exam.
Make it yours
Choose a game object, pet, an old program to refactor or invent your own class idea. Personal knowledge can make the modelling decisions more interesting.
Still catching up?
Return to the relevant OOP technique or unfinished challenge instead. You do not need additional work before the controlled checkpoint.
Checkpoint exam
Your teacher runs the final assessment separately in class. The site does not publish or preview that task.
Challenges Choose one
Choose a challenge that feels appropriate for you. Code heat is only a rough estimate, not a fixed level.
Favourite Game Object
SelectedChoose one thing from a game you like: a player, creature, weapon, vehicle, item, building or another sensible object. Design one class for it in UML, then code it. Give each object meaningful independent state and at least two behaviours, including one behaviour that changes state while protecting a sensible rule or boundary. Create at least two objects and prove that changing one does not accidentally change the other. Add a class-owned/static member only if the idea genuinely belongs to the whole class rather than each object.
Keep it to one class. The point is to make good OOP decisions in a context you already understand, not recreate the whole game.
Pet Simulator
SelectedCreate a class for a dog, cat or other pet. Choose the state that matters in your model: for example name, breed, energy, hunger, happiness or age. Add actions such as play, feed, train, rest or walk that change the object's state. Decide what values or actions should be impossible and make the class reject them rather than allowing invalid state. Draw the UML first, then create at least two pets with different starting values and demonstrate their independent behaviour.
You choose the rules. A dog does not need the same attributes or behaviours as somebody else's dog.
Objectify an Old Program
SelectedChoose one earlier program you made before OOP. Find one concept inside it that could sensibly become an object: perhaps a player, account, quiz attempt, product, booking, score record or something else. Redesign only that part as a class, sketch the UML, then refactor the program to use at least two objects. Finish with a short explanation of one thing the class design improved and one piece of extra complexity it introduced.
Do not convert every variable into a class. Choose one concept where keeping related state and behaviour together actually helps.
Three Ideas, One Class
SelectedThink of three possible classes from your own interests or everyday life. They could come from sport, music, games, school, travel, food, collections or anything suitable. For each idea, sketch a tiny UML box with possible attributes and behaviours. Choose the design that has the clearest responsibility, improve its UML, then code and test that one class with at least two objects. Include one controlled state-changing operation so the object is responsible for one of its own rules.
This is deliberately open. The exploration and design choice are part of the challenge.
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.