Programming technique · B3.1.1
Why object orientation?
Object-oriented programming groups related state and behaviour into objects. It can make repeated or changing entities easier to model, but it is not automatically the clearest choice for every program.
The essential vocabulary
Class
A design or type from which objects can be created.
Object
One instance with its own identity and current state.
Encapsulation
Keeping related state and responsible behaviour within a controlled boundary.
Inheritance
A later HL mechanism for extending a parent design through child classes.
Polymorphism
A later HL mechanism allowing a shared type to produce specialised behaviour.
A small object model
The class keeps related values and behaviour together. The object named before describe() is the receiver of that method call.
The class keeps related values and behaviour together. The object named before describe() becomes self while that method runs.
Evaluate rather than advertise
Possible strengths
- Related state and behaviour stay together.
- Many objects can follow the same design while keeping independent state.
- Responsibilities can become easier to discuss, test and extend.
- Well-designed classes can be reused in more than one part of a program.
Possible limitations
- Classes, initialisation and method calls add structure and terminology.
- Poor class boundaries can spread responsibility rather than clarify it.
- Following interactions across many objects can add indirection.
- A tiny calculation may be clearer as a direct procedure.
Make the judgement fit the scenario
Repeated entities?
Several students, products or game characters may justify one reusable class design.
Related state and actions?
An object is more convincing when its values and operations belong to one clear responsibility.
Only one short calculation?
Do not add a class merely because OOP is available.
Challenges Choose one
Choose a challenge that feels appropriate for you. Code heat is only a rough estimate, not a fixed level.
Mission Record Model
SelectedCreate one MissionRecord class containing a name, level, constructor and returning describe method. Create two objects with different values and prove that changing one object does not change the other. Finish with a short balanced evaluation: explain one reason the class helps this repeated-record scenario and one cost compared with a tiny one-off program.
One-Off Converter Decision
SelectedWrite a short temperature conversion program using ordinary methods and variables. Then decide whether introducing a dedicated TemperatureConverter object would improve this particular one-off program. Support your judgement with evidence about related state, repeated objects, reuse and extra structure. There is no single required answer when the reasoning fits the program.
Game Character Appraisal
SelectedCreate a small GameCharacter class and two character objects with independent names and energy values. Add one state-changing method and one returning summary method. Evaluate the design by weighing cohesion, independent state and future extension against the additional class structure and method calls.
Selected challenge
This choice is shared with the portfolio setup page.
Create your challenge folder
Run this command before starting. It creates the correct empty folder inside your portfolio.
Complete the challenge
Write and test your own solution in the folder created above.
Optional scaffolded support
Use only as much support as you need. The templates organise the program but leave the important algorithm unfinished.
Submit for review
Run this when your program is complete. It creates the README, commits the folder and pushes it.