Path 80 · The object workshop · Intermediate
Make invalid transitions visible.
A guided, practical route through java object design.
What you will be able to do
Model a small lending item with explicit state transitions and test checkout and return behavior.
Plan about 8h 18m in total. Reading and practice are editorial estimates; video runtimes come from public provider metadata. Your pace will vary.
Before you begin
Check your starting point
What you need
Basic programming and a local Java JDK. The package is a local reference, not a deployed library system.
The selected public provider lessons are free to view. The original case can be completed with paper, a text editor or freely available local tools. Paid exams, certificates, subscriptions and optional provider software are not required for this project.
Completing this WikiFree path does not award a provider certificate. Any provider assessment, account requirement or credential must be checked separately on its official page.
Three readiness questions
Should callers modify the state field directly?
No. Use methods that preserve the rules.
What should a rejected action change?
Nothing in the object state.
Is an in-memory object a persistent database record?
No.
Use a workable pace
At 5 hours per week, allow about 2 weeks. Start with Stage 1, continue in order and reserve 2h for the capstone. If a gate fails, use its repair step before advancing. At another weekly budget, divide 498 estimated minutes by your available weekly minutes and round up.
Keep a small evidence folder. A checked box means you reviewed your output; it is not a certificate or proof that a provider lesson was watched.
The working case
Two states, guarded transitions
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 |
The table and explanations preserve the essential case information when the diagram is unavailable.
Your route
Five outputs, then a final handoff
- 01Identify state and behaviorClass contract
About 1h 16m including assigned learning and practice. - 02Implement guarded methodsEncapsulated class
About 1h 26m including assigned learning and practice. - 03Exercise the transition sequenceTransition checks
About 1h 34m including assigned learning and practice. - 04Explain identity and collectionsExtension design
About 1h 14m including assigned learning and practice. - 05Document the boundaryJava source handoff
About 50m including assigned learning and practice. - FINALCapstone reviewCombine the evidence into one inspectable handoff.
About 2h .
0 of 6 outputs checked. JavaScript adds browser-only progress saving.
The complete lesson and all downloads remain available. Use the printable project workbook to track your progress.
Use the minimum useful source material
The courses behind this route
Microsoft
Free Java Programming Course for Beginners
The existing Java classes, methods, testing and collections lessons map directly to the object exercise.
Selected material only; this path does not claim completion of the entire provider course.
Course publication and selected public lesson metadata were checked on 13 October 2026. This is not a claim of full video playback, provider-course completion or permanent availability. Recheck the linked source if a lesson changes.
Learn, make, inspect
The five-stage workshop
Identify state and behavior
Video 15m · reading budget 0m · original practice about 1h .
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.
Watch these selected lessons
Do the work
Sketch the class and list its allowed transitions.
Save this output
Class contract
Pass the review gate
Only two states and two meaningful operations are needed.
If you need another attempt
Remove fields that do not belong to the stated case.
Implement guarded methods
Video 10m · reading budget 0m · original practice about 1h 15m.
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.
Watch these selected lessons
- Java Methods Part 110:26
Do the work
Implement checkout and returnItem methods.
Save this output
Encapsulated class
Pass the review gate
A duplicate checkout returns false and keeps the item on loan.
If you need another attempt
Check the state before assigning the new state.
Exercise the transition sequence
Video 14m · reading budget 0m · original practice about 1h 20m.
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.
Watch these selected lessons
- Java Testing13:38
Do the work
Run the five-row sequence in a local JDK and compare each result.
Save this output
Transition checks
Pass the review gate
Rejected actions preserve the previous state.
If you need another attempt
Reset fixtures between independent cases.
Explain identity and collections
Video 8m · reading budget 0m · original practice about 1h 5m.
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.
Watch these selected lessons
- Java Collections8:24
Do the work
Design a two-item extension and a duplicate-ID policy.
Save this output
Extension design
Pass the review gate
The policy distinguishes an item ID from a human-readable label.
If you need another attempt
Define duplicate behavior before adding an item.
Document the boundary
Video 0m · reading budget 0m · original practice about 50m.
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.
Original application stage. Use your preceding outputs and the supplied case; there is no additional required provider lesson.
Do the work
Package the class, a check runner and expected sequence.
Save this output
Java source handoff
Pass the review gate
Execution status is explicit and persistence is not claimed.
If you need another attempt
Separate expected behavior from an actual local run log.
Make the result inspectable
Your final project
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.
The ZIP includes synthetic input data, a project workbook, worked reference, evidence log, scoring rubric and case-specific materials. Code projects include source and clearly stated local execution requirements.
Use one consistent rubric
| Criterion | Maximum | 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 critical condition
State is private and rejected operations leave it unchanged; supplied source is not represented as a compiled result.
Compare with a worked reference
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.
Know the boundary
This is in-memory object design, not a persistent or concurrent lending service.
Questions before you finish
Do I need to finish every source course?
No. This path names selected lessons or reading sections. Complete the full provider course only if it supports your wider goal. The path does not claim equivalence to that course.
How do I know when to advance?
Use the output and review gate in each stage. If evidence is missing or a result conflicts with the case, follow the repair step and retry before advancing.
Can I do the project without paid software?
The selected public provider lessons are free to view. The original case can be completed with paper, a text editor or freely available local tools. Paid exams, certificates, subscriptions and optional provider software are not required for this project.
What does my checklist prove?
It records your own review in this browser only. It does not verify viewing, skill, a provider credential or a real-world deployment.
What if a lesson or tool changes?
Use the linked course and provider page to inspect current availability. Record the change and revisit the relevant assignment; do not invent a replacement lesson or claim an unavailable activity was completed.
Questions & discussion
Share a useful question or correction. Comments appear after moderation. Please avoid personal or sensitive information.