OOD Fundamentals
OOP Foundations
SOLID Principles
Creational Patterns
Structural Patterns
Behavioral Patterns
Classic OOD Problems: Part 2
Design a Library Management System
A library management system is a relationship-management problem at its core. Books exist in a catalog. Physical copies of those books sit on shelves. Members borrow copies, return them, and sometimes pay fines for keeping them too long. Underneath this simple workflow lies a rich set of design decisions: how do you distinguish a catalog entry from a physical item? How do you enforce borrowing limits? How do you handle reservations when all copies are checked out?
The reason this problem appears in OOD interviews is that it tests your ability to model real-world relationships between entities: one-to-many (book to copies), many-to-many (members to books through borrowings), and temporal relationships (borrowings have start dates, due dates, and return dates).
Actors and Interactions
Three actors interact with the system:
Members browse the catalog, borrow books, return books, pay fines, and reserve books that are currently unavailable.
Librarians add books to the catalog, register new members, process checkouts and returns, and manage fines and reservations.
The system itself enforces borrowing limits, calculates due dates and fines, sends reservation notifications, and maintains catalog search indexes.
Functional Requirements
- Maintain a catalog of books with title, author, ISBN, and category
- Track multiple physical copies per book (each with a unique barcode)
- Register members with borrowing limits based on membership tier
- Process checkouts: find an available copy, create a borrowing record, mark the copy as unavailable
- Process returns: mark the copy as available, calculate any overdue fine
- Search the catalog by title, author, ISBN, or category
- Reserve books that have no available copies, with notification when one becomes available
Non-Functional Requirements
- Data integrity: a copy cannot be checked out to two members simultaneously
- Auditability: every checkout, return, and fine should be recorded
- Fairness: reservations are served in FIFO order
The most common mistake in library system design is treating Book and BookCopy as the same entity. A library owns three copies of 'Clean Code': that is one Book with three BookCopy objects. If you merge them, you cannot track which specific copy a member borrowed, which copy is damaged, or how many copies are available. This Book vs BookCopy distinction is the central modeling insight of the entire problem.
Core Entities Preview
- Book: catalog entry with title, author, ISBN (one per unique title)
- BookCopy: physical item with barcode, condition, availability status (many per Book)
- Member: library user with name, ID, membership tier, borrowing limit
- Borrowing: links a Member to a BookCopy with checkout date and due date
- Fine: calculated from overdue Borrowing records
- Reservation: a queue of Members waiting for a specific Book to become available
- Library: the top-level class that orchestrates all operations