Model a small lending item with explicit state transitions and test checkout and return behavior.
A fictional club lends one tool with ID T1. It starts available, can be checked out once, rejects a second checkout, can be returned once and rejects a second return. This single-object exercise has no users, database or concurrent requests.
| Action | Expected state | Expected result |
|---|---|---|
| Start | available | initial |
| Checkout | on loan | accepted |
| Checkout again | on loan | rejected |
| Return | available | accepted |
| Return again | available | rejected |
An object groups a coherent state with operations that preserve its rules. Keep the item identifier stable and make availability private. A class should not expose arbitrary writes that bypass checkout and return. This case is intentionally small enough to describe every valid transition in a table.
Sketch the class and list its allowed transitions.
Class contract
Record your result and evidence here or in a separate file.
Only two states and two meaningful operations are needed.
Remove fields that do not belong to the stated case.
A method should check its precondition before changing state. Choose a clear result for a rejected operation, such as a boolean, and document it. Do not partially mutate the object before discovering failure. Keep console printing outside the core class so behavior can be tested independently.
Implement checkout and returnItem methods.
Encapsulated class
Record your result and evidence here or in a separate file.
A duplicate checkout returns false and keeps the item on loan.
Check the state before assigning the new state.
Tests should cover successful and rejected transitions and inspect state after each. A test that only checks printed text can miss a corrupted object. Use assertions or explicit checks that fail the process. Keep the test fixture isolated so each scenario starts from a known state.
Run the five-row sequence in a local JDK and compare each result.
Transition checks
Record your result and evidence here or in a separate file.
Rejected actions preserve the previous state.
Reset fixtures between independent cases.
A collection can hold multiple lending items, but searching by ID introduces another rule: IDs should be unique within that collection. Do not add a database or concurrency layer merely to demonstrate collections. A simple registry extension can show how object identity and lookup differ from a display name.
Design a two-item extension and a duplicate-ID policy.
Extension design
Record your result and evidence here or in a separate file.
The policy distinguishes an item ID from a human-readable label.
Define duplicate behavior before adding an item.
A useful README explains the state machine, run commands and limitations. This source does not persist after process exit and cannot safely coordinate simultaneous checkouts from multiple processes. The preparation environment lacks javac, so compilation and runtime checks remain learner tasks rather than claimed verification.
Package the class, a check runner and expected sequence.
Java source handoff
Record your result and evidence here or in a separate file.
Execution status is explicit and persistence is not claimed.
Separate expected behavior from an actual local run log.
Deliver the class contract, source, transition checker and README. Add a second item and demonstrate that operating on one does not alter the other, using a local JDK when available.
State is private and rejected operations leave it unchanged; supplied source is not represented as a compiled result.
| Criterion | Points | Evidence |
|---|---|---|
| Evidence and correctness | 30 | Calculations, source use and results match the supplied case; limitations are honest. |
| Required artifacts | 30 | All five stage outputs and the capstone handoff are present and inspectable. |
| Reasoning and decisions | 20 | Choices, assumptions, alternatives and the case-specific critical condition are explained. |
| Reproducibility | 10 | A reviewer can follow the stated steps and distinguish expected from observed results. |
| Clear communication | 10 | Labels, units, structure and evidence references make the work easy to review. |
Score at least 80/100, supply every required artifact, and satisfy the path-specific critical condition. Rework missing evidence before marking complete.
The state sequence is available → on loan → on loan → available → available. The operation results are true, false, true, false. A rejected action leaves state unchanged. The bundled Java source has not been compiled in the preparation environment.
This is in-memory object design, not a persistent or concurrent lending service.