Java OOP capstone: modelling a library service
≈ 45 minJava OOP capstone: modelling a library service
A capstone design starts from behaviour, not from a list of Java keywords. For a library service, decide what must remain true: a book cannot have two active loans; a member cannot exceed a borrowing limit; returning a book closes the active loan. Then assign each rule to an object that owns the needed state and can expose a clear method.
A small service object can coordinate a use case while domain objects protect their own invariants. LibraryService may find a Book and Member, then ask book.borrowTo(member, today). It should not set private fields by itself. This separation lets unit tests cover Book and Loan rules, while integration tests cover the borrowing workflow.
Worked reasoning. Design Book with identifier and availability, Member with active-loan count, Loan with dates and status, and LibraryService with repository interaction. A borrow request checks the member limit, asks Book whether it is available, creates a Loan and records the state transition. A return request closes the Loan and asks Book to become available again.
Exam lens. In a design answer, show one invariant and the method that protects it. Explain how the collaboration avoids a god class and why each class has a focused purpose.
Uses Uvero's optional secure Java practice service. If it is unavailable, your lessons and progress still work.
Which statement is the most defensible principle for Java OOP capstone: modelling a library service?
Enter the key term for Java OOP capstone: modelling a library service. What design principle says a class should have one coherent reason to change?
Which object should decide whether a particular Book is currently available to borrow?
Name the concise safeguard or principle that completes this lesson’s scenario: Which object should decide whether a particular Book is currently available to borrow?

