Module 19: Advanced Capstone Portfolio
Capstone 1: Console Library Manager
Build a console-based library manager that demonstrates clean object design, collections, validation, and basic persistence or file export. This capstone is strong when the workflow is clear and the data model is easy to extend, not when it has dozens of commands.
Author
Java Learner Editorial Team
Reviewer
Technical review by Java Learner
Last reviewed
2026-04-17
Java version
Java 25 LTS
Learning goals
- Model a small domain with classes, collections, and command-driven workflows
- Design console interactions that validate input and preserve consistent state
- Ship a complete, well-structured project that is easy to demo and extend
Before you start
- You are comfortable with OOP, collections, exceptions, and file or persistence basics
Lesson roadmap: Start with the mental model, then follow the design choices, common pitfalls, and the practical workflow you should apply in a real project.
Project goal: Build a console-based system that tracks books, members, and loan state clearly.
What to practice: Domain modeling, collection choices, validation, reporting, and a simple persistence boundary.
Stretch ideas: Add overdue checks, sorted reports, persistence to files or a database, and role-based actions.
Success check: The project should feel like a real small application, not a pile of unrelated methods.
Project goal: Manage books, members, and borrowing status from the console. The simplest useful version supports adding books, listing them, checking books out, returning them, and searching by ID or title.
Suggested design: Create classes such as Book, Member, and LibraryService. Use maps for fast lookup by ID and lists when order matters for display.
Milestone plan: First support adding and listing books, then add members, then borrowing and return flows, then validation and reporting. Small milestones keep the command loop manageable.
Stretch ideas: Save data to a file, track due dates, or add simple overdue reporting. These are good extensions only after the core state transitions are reliable.
How to use the capstones: Build them like portfolio pieces, not toy exercises. Write down the scope first, finish a thin vertical slice, and only then add polish, tests, extra features, or deployment steps.
Project review mindset: A strong capstone shows design choices, not just code volume. Clear boundaries, naming, validation, error handling, and a short README often matter more than adding ten extra features.
Delivery habit: Each finished project should include a problem statement, setup instructions, example input and output, and at least one obvious next improvement for future iteration.
Runnable examples
A map fits member lookup by ID
Map<Integer, Member> membersById = new HashMap<>();Expected output
Key-based lookup is a natural fit for member retrieval by ID.
A map is a natural fit for ID-based lookup
Map<Long, Book> booksById = new HashMap<>();
booksById.put(101L, new Book(101L, "Clean Code"));Expected output
The system can locate a book by ID quickly without scanning the whole collection.
Common mistakes
Putting all command parsing and business logic into `main`
Move library operations into a service class so the command loop stays small.
Skipping state validation for borrow and return actions
Explicitly guard rules such as “cannot borrow an already borrowed book.”
Mini exercise
Write the first four commands for the library manager and the classes each command will call. Then list one validation rule for borrowing and one for returning.
Summary
- This capstone is about domain modeling and rule enforcement.
- Collection choices should match the real lookup and reporting tasks.
- A larger CLI app is a strong proof of practical Java fluency.
- A console capstone is strongest when the domain model and workflows are clear.
- Collections and command parsing should support the model, not dominate it.
Next step
The next capstone moves from domain management to file-driven data processing.
Sources used