Community resourceWorksheet
OCR H446 1.2.4 Encapsulation and controlled object state
Part 7 of 10 · H446 1.2.4 · Types of programming language
Encapsulation is often reduced to making things private, which does not earn the marks at H446 1.2.4. Students connect visibility to the rule an object must keep true, repair an unsafe public interface and then design controlled access for a class of their own.
Students will:
- explain encapsulation as controlled access that protects a rule about object state
- describe what an unprotected public attribute allows any caller to do
- redesign a class whose public attributes permit an invalid combination of values
- specify which values a state-changing method should reject
- compare a controlled method interface with directly writable public data
Inside: 5 explanation cells, 1 multiple-choice question, 2 fill-in-the-blanks cells and 2 written answers. 20 marks, about 35 to 45 minutes.
Series: H446 1.2.4 · Types of programming language, part 7 of 10.
Shared by Coding PathwayVerified teacher
- 10 cells
- About 45 minutes
- CC BY-SA 4.0
- Shared 31 Aug 2026
- Updated 3 Sept 2026
Preview
The whole resource, exactly as a class sees it. Answers and marking are held back.
Encapsulation and controlled state
Encapsulation groups state with the methods that manage it and restricts uncontrolled access. The purpose is not to hide everything: it is to protect a valid interface and preserve rules about state.
Visibility supports an invariant
A ticket object has private remainingUses. The invariant is remainingUses >= 0. A public use() method checks the value before subtracting one; a public getRemainingUses() method returns the value without exposing direct mutation.
If the attribute were freely writable, another part of the program could set it to −12 or a string. Private visibility plus controlled methods creates one place to validate changes. The object is easier to reason about because its own code protects its valid state.
Worked repair
Unsafe interface: public balance, so any caller can assign any value.
Repair: make balance private; initialise it through the constructor; provide deposit(amount) that accepts only positive amounts; provide getBalance() for read access. If withdrawals are required, a method can reject amounts greater than the balance.
Mechanism → direct writes are restricted. Consequence → the class can preserve its rules and callers use a stable interface.
Which explanation best describes encapsulation?
- AMaking every method private
- BStoring all objects in one global variable
- CPreventing a class from having methods
- DGrouping state and behaviour while controlling access through an interface
- private
- public
- invariant
- paradigm
A TemperatureLog class exposes public highest and lowest attributes. Any caller can set highest below lowest. Redesign the interface and explain how your design preserves valid state.
Name visibility, at least one controlled update method and its validation rule, then state the consequence.
Students type their answer here.
Apply the model independently
The remaining tasks change the context or reduce the support. Complete them without copying the worked model, then check that each explanation connects a mechanism to its consequence.
A game profile has private experience and public methods award(points) and getLevel(). Explain two benefits of this interface compared with public writable experience. Include what award should reject and how the level can be derived consistently.
Develop each benefit as mechanism → consequence.
Students type their answer here.
Review your understanding
Before submitting, check that you can explain the main distinction in your own words, apply it in an unfamiliar context and justify each consequence rather than only naming a feature.