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.
Start with the problem, not the terminology
One approach is to keep adding separate variables, arrays and helper functions. Another is to give each character one object that owns the data and behaviour belonging to that character.
Think first
What becomes difficult if the program grows from 3 characters to 30 or 300?
Do values belong together?
A character's name, health and level describe one entity. Losing that connection makes code harder to reason about.
Do actions belong with the data?
Attack and heal are easier to discuss when we know which character receives the action.
What you need to be able to do
Recognise the model
Distinguish classes and objects and recognise what encapsulation, inheritance and polymorphism contribute to an object-oriented design.
Explain the purpose
Explain how an object can group related state and behaviour while many objects share one class design.
Evaluate the choice
Judge whether OOP makes a stated problem clearer or merely adds unnecessary structure.
From a procedural problem to an object model
Suppose we track three virtual pets. Each pet has a name, hunger and happiness, and can be fed, played with and asked to describe its state.
| Procedural idea | What can become awkward as the program grows? | Object-oriented idea |
|---|---|---|
| Separate variables for every pet | Many names are needed and related values are easy to separate accidentally. | One Pet object stores one pet's state. |
| Parallel arrays or lists | Indexes must stay aligned across every collection. | Each object's values travel together. |
| Helper functions with an index or many parameters | The caller repeatedly identifies which values belong to the target pet. | Call behaviour on the object that should receive it. |
Nouns suggest state; verbs suggest behaviour
Nouns / data
name, hunger and happiness are candidates for attributes.
Verbs / actions
feed, play and describe are candidates for methods.
The entity
The overall thing being modelled becomes a candidate class: Pet.
The essential vocabulary
Class
A reusable design or type from which objects can be created.
Object
One concrete instance with its own identity and current state.
Attribute
Data that describes part of an object's state.
Method
Behaviour defined by the class and called for an object or class.
Constructor / initialiser
Code used to establish a new object's starting state.
Instance
Another word for a particular object created from a class.
Recognise the five OOP fundamentals named by the standard
B3.1.1 is an evaluation standard. At this point you do not need to construct HL inheritance hierarchies or polymorphic dispatch. You do need enough conceptual understanding to recognise what each fundamental contributes when evaluating an object-oriented design.
Class
Defines the common state and behaviour expected from a type of object. It can reduce repeated definitions when many similar entities are needed.
Object
One concrete instance of a class with its own identity and state. Multiple objects can follow one class design while storing different values.
Encapsulation
Keeps related state and behaviour behind a deliberate object interface so the object can control how its state is read or changed.
Inheritance
Lets a specialised class reuse or extend a more general class when there is a genuine is-a relationship. This can reduce duplication, but it also couples the child to parent design decisions.
Polymorphism
Lets related object types respond to the same operation in different valid ways. This can keep callers simpler, but it depends on a sound shared design.
Check the model before coding
Answer each question before opening the model answer.
-
Milo and Luna were both created from Pet. Are they two classes or two objects?
Reveal model answer
They are two objects (two instances) of the same Pet class.
-
In the virtual-pet example, is hunger more naturally an attribute or a method?
Reveal model answer
An attribute, because it stores part of each pet object's current state.
-
Why is feed() more naturally a method than a separate variable?
Reveal model answer
It describes behaviour: an action that can use or change the state of the receiving pet.
-
A game has Warrior and Mage as specialised kinds of Character that reuse shared Character features. Which OOP fundamental describes that general relationship?
Reveal model answer
Inheritance. The specialised types reuse or extend a more general type. At SL you only need to recognise and evaluate that role here; the implementation mechanics are taught later at HL.
-
Warrior and Mage both support an action called attack(), but each can perform it differently. Which fundamental does that illustrate?
Reveal model answer
Polymorphism: related object types can provide different valid behaviour through the same operation.
-
If a program only converts one temperature once, must it use a class?
Reveal model answer
No. A direct procedural solution may be clearer when there is little related state, no repeated entities and no useful object responsibility.
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
OOP is a design choice, not a quality label. A good evaluation connects the advantages and disadvantages to the actual problem.
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, books 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.
Likely to grow or change?
A clear object boundary can make future extension easier, but only when the boundary itself makes sense.
Only one short calculation?
Do not add a class merely because OOP is available.
Can you evaluate the design choice?
Give a reason tied to the scenario before revealing each model answer.
-
A library stores thousands of books, each with its own title, author and loan state. Why might OOP help?
Reveal model answer
Books are repeated entities with related state and behaviour. One LibraryBook class can define the common design while each object keeps independent values.
-
A program reads one number, doubles it and prints the answer. What is the strongest argument against introducing a class?
Reveal model answer
The extra class structure is unlikely to clarify such a small one-off calculation; a direct procedure is easier to follow.
-
Is “OOP is reusable” enough for an evaluation answer?
Reveal model answer
Not by itself. Explain what would actually be reused or extended in the stated scenario, and balance that benefit against any added complexity.
Apply the idea
Now choose a challenge. You are not trying to prove that OOP is always better; your final judgement should match the program you actually build.
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.
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.