Encapsulation
Encapsulation places state behind operations that preserve a documented invariant. Hiding a field is useful when callers must not bypass the rules that make the object valid.
What you’ll understand
- Encapsulation places state behind operations that preserve a documented invariant. Hiding a field is useful when callers must not bypass the rules that make the object valid.
- Wallet.withdraw validates the amount before changing private balance state and returns whether the transition succeeded.
- Evaluate the tradeoff: Validation adds code and can restrict flexibility. Expose the smallest useful set of operations, and distinguish language-enforced privacy from naming conventions.
Useful first: Classes and Objects
The idea and when to recognize it
Encapsulation places state behind operations that preserve a documented invariant. Hiding a field is useful when callers must not bypass the rules that make the object valid.
- Requirement: A wallet balance must never become negative. Callers need a withdrawal operation with an explicit success result.
- Change to anticipate: Reject withdrawals above the balance and nonpositive amounts while preserving the original balance after a rejected operation.
- Design goal: Wallet.withdraw validates the amount before changing private balance state and returns whether the transition succeeded.
Start with the concrete problem
A wallet balance must never become negative. Callers need a withdrawal operation with an explicit success result.
Reject withdrawals above the balance and nonpositive amounts while preserving the original balance after a rejected operation.
| Direct implementation | Revised design |
|---|---|
| Updating a public balance directly allows callers to skip validation and make the wallet invalid. | Wallet.withdraw validates the amount before changing private balance state and returns whether the transition succeeded. |
| The baseline case can hide the problem. Compare the extension and boundary fixtures before accepting this design. | Validation adds code and can restrict flexibility. Expose the smallest useful set of operations, and distinguish language-enforced privacy from naming conventions. |
Responsibilities and contracts
Wallet.withdraw validates the amount before changing private balance state and returns whether the transition succeeded.
- Wallet: Protects a nonnegative balance. Public operations: withdraw(amount), balance
- Caller: Requests a withdrawal. Public operations: withdraw(amount)
Read the design
Select a participant to inspect its responsibility and public operations. Follow the labeled relationships; an arrow indicates direction, while the legend distinguishes ownership, substitution, and temporary use.
Preparing the design walkthrough…
Follow the interaction
Choose a supplied workload and compare the direct and revised implementations. Step through the same operation in both languages. Object values are recorded after each highlighted statement; previous steps remain unchanged.
Preparing the design walkthrough…
Implementation and expected output
Read the complete example alongside its input and expected output. The implementation selector changes the displayed program; the language selector preserves your current scenario and playback position.
Preparing the design walkthrough…
Try the idea in another setting
An inventory object can expose reserve and release operations instead of allowing callers to overwrite available stock.
- Name the new client contract before adapting the example.
- Identify which state belongs to each object and who controls its lifetime.
- Write one normal case and one boundary case before extending the design.
Tradeoffs and interview takeaways
Validation adds code and can restrict flexibility. Expose the smallest useful set of operations, and distinguish language-enforced privacy from naming conventions.
Common mistake: Updating a public balance directly allows callers to skip validation and make the wallet invalid.
- Explain the choice: Wallet.withdraw validates the amount before changing private balance state and returns whether the transition succeeded.
- Challenge your choice: Validation adds code and can restrict flexibility. Expose the smallest useful set of operations, and distinguish language-enforced privacy from naming conventions.
- Describe a requirement that would make the simpler implementation sufficient.
Design challenge and knowledge check
Preparing the design walkthrough…