Library Management System
Title identity, copies, and loan ownership
A title identifies a logical work; a copy identifies one lendable physical instance. Multiple copies of the same title may be loaned to different members, but a member's active title constraint spans every copy.
type CopyID string
first, second := CopyID("C1"), CopyID("C2")
fmt.Println(first != second) // distinct copies can share a titleCheck duplicate member-title ownership before checking availability, so exhaustion does not hide an invalid duplicate request. Return operations need the current loan owner; unknown and already returned copies are harmless misses, while another owner's return is an error. Store immutable inventory separately from mutable loans. Deterministic smallest-copy allocation keeps behavior reproducible.
Go models this service with a struct and pointer-receiver methods. Constructor functions return a pointer; validation failures return errors rather than panicking. Scalars in snapshot structs are copied by value. Maps, slices, and optional pointers still require detached copies when crossing the service boundary. Go maps do not have key iteration order; use ordered slices for ranked results. There are no threads, persistence, wall-clock reads, or external side effects in this exercise.
Put it into practice
Implement the exercise in a full-screen workspace, then run its tests.