Programming technique · B3.1.5
Encapsulation and information hiding
An object should own the rules that protect its state. External code uses a deliberate interface instead of changing the internal representation without checks.
private and public access modifiers. A leading underscore signals internal use; double underscores trigger name mangling. Good encapsulation still depends on a deliberate interface and valid-state rules, not on pretending access is impossible.The object owns the rule
Caller
Requests an operation
EnergyCell boundary
checks before changing charge
reports without unrestricted mutation
state governed by the object
- charge: int + EnergyCell(initialCharge: int)+ use(amount: int): boolean+ getCharge(): int - __charge: int + __init__(initial_charge)+ use(amount): bool+ get_charge(): int Apply the boundary in Java
Apply the boundary in Python
Trace every path
| Request | Check | Result | Charge after request |
|---|---|---|---|
| create with 12 | not negative | object created | 12 |
use(5) | positive and enough charge | true | 7 |
use(20) | insufficient charge | false | 7 — unchanged |
use(0) | not positive | false | 7 — unchanged |
Encapsulation and information hiding are related
Encapsulation
Keep state and the behaviour responsible for that state together inside a class boundary.
Information hiding
Limit reliance on the internal representation so callers depend on deliberate operations instead.
Hidden state alone is not enough
An unsafe method can still place internal state into an invalid condition.
Do not create setters automatically
Expose operations that match responsibility rather than unrestricted writes for every attribute.
Security has a boundary
Access control and conventions protect program design; they do not automatically provide encryption or authentication.
Challenges Choose one
Choose a challenge that feels appropriate for you. Code heat is only a rough estimate, not a fixed level.
Library Book
SelectedCreate a LibraryBook class with private title and borrowed state. External code must use public borrow, returnBook and getStatus operations rather than changing fields directly. Reject impossible repeated borrow or return requests and prove that rejected requests leave the object in a valid state.
Product Class
SelectedCreate a Product class with private code, name and price fields. The constructor and updatePrice method must preserve the rule that price is greater than zero. Provide a returning summary operation, test accepted and rejected changes and explain why private fields alone would not help if public methods allowed invalid values.
Temperature Sensor
SelectedCreate a TemperatureSensor with one private reading and a documented valid range. Validate the starting value, provide a guarded updateReading command and a read-only getTemperature query. Test both boundaries and prove that a rejected update does not alter the previous valid state.
Password Vault Model
SelectedBuild a classroom PasswordVault model with one private stored code. Public methods may check an attempt and update the code only when the current code is correct and the replacement satisfies a documented rule. Never return the stored code. Explain that private access supports information hiding inside this program but is not encryption or complete real-world password security.
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.
Shared OOP foundation complete
You have evaluated OOP, designed and instantiated classes, distinguished class-owned and instance-owned members, and applied controlled state boundaries. The remaining OOP topics are higher-level extensions.