Class design (Book, Member, Librarian, Loan) in LLD - System Design Exercise

Design: Library Management System

Design the core classes and their relationships for managing books, members, librarians, and loans. Exclude UI and database implementation details.

Functional Requirements

FR1: Allow members to borrow and return books

FR2: Track which books are loaned and their due dates

FR3: Librarians can add, update, and remove books

FR4: Members can view their loan history and current loans

FR5: Support multiple members and librarians

Non-Functional Requirements

NFR1: Handle up to 10,000 members and 100,000 books

NFR2: Operations should be efficient for quick lookups

NFR3: Ensure data consistency for loans and returns

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

Key Components

Book class with details like title, author, ISBN

Member class with personal info and loan records

Librarian class with permissions to manage books

Loan class to represent borrowing details

Design Patterns

Association between Member and Loan

Inheritance if Librarian and Member share common user attributes

Encapsulation to protect class data

Use of methods to perform borrow and return actions

Reference Architecture

Library Management System Classes

+----------------+       +----------------+       +----------------+
|     Book       |       |    Member      |       |   Librarian    |
+----------------+       +----------------+       +----------------+
| - bookId       |       | - memberId     |       | - librarianId  |
| - title        |       | - name         |       | - name         |
| - author       |       | - email        |       | - email        |
| - ISBN         |       | - loans: List  |       |                |
| - isAvailable  |       +----------------+       +----------------+
+----------------+               |                          |
         ^                       |                          |
         |                       |                          |
         |                       |                          |
         |                       |                          |
         |                       |                          |
         |                       |                          |
         |                       v                          v
         |               +----------------+
         |               |      Loan      |
         |               +----------------+
         |               | - loanId       |
         |               | - book: Book   |
         |               | - member: Member|
         |               | - loanDate     |
         |               | - dueDate      |
         |               | - returnDate   |
         |               +----------------+

Components

Book

Class

Represents a book with details and availability status

Member

Class

Represents a library member with personal info and loan records

Librarian

Class

Represents a librarian who manages books

Loan

Class

Represents a loan record linking a book and a member with dates

Request Flow

1. Member requests to borrow a book

2. System checks if the book is available

3. If available, create a Loan object with loanDate and dueDate

4. Mark the book as not available

5. Add the loan to the member's loan list

6. Member returns the book

7. System updates the Loan with returnDate

8. Mark the book as available again

9. Librarian adds or updates book details in the system

Database Schema

Entities: - Book(bookId PK, title, author, ISBN, isAvailable) - Member(memberId PK, name, email) - Librarian(librarianId PK, name, email) - Loan(loanId PK, bookId FK, memberId FK, loanDate, dueDate, returnDate) Relationships: - One Member can have many Loans (1:N) - One Book can have many Loans over time (1:N) - Loan links one Book and one Member

Scaling Discussion

Bottlenecks

Searching books by title or author becomes slow with many books

Tracking loans for many members can cause performance issues

Concurrent borrow requests for the same book may cause conflicts

Solutions

Use indexing on book attributes for fast search

Paginate loan records and cache frequent queries

Implement locking or transactions to prevent double borrowing

Interview Tips

Time: Spend 10 minutes understanding requirements and clarifying scope, 20 minutes designing classes and relationships, 10 minutes discussing scaling and improvements, 5 minutes summarizing.

Explain class responsibilities clearly

Show relationships and how they support requirements

Discuss how to handle book availability and loan tracking

Mention data consistency and concurrency handling

Highlight how the design can scale with more users and books

Practice

1. Which class should be responsible for storing information about a book's title, author, and ISBN in a library system?

easy

A. Member

B. Book

C. Librarian

D. Loan

Solution

1. Step 1: Identify the class representing a book

   The class named Book logically holds details about books such as title, author, and ISBN.

2. Step 2: Confirm other classes' roles

   Member is for library users, Librarian manages operations, and Loan tracks borrowing, so they don't store book details.

3. Final Answer:

   Book -> Option B

4. Quick Check:

   Book class stores book info [OK]

Hint: Book class holds book details like title and author [OK]

Common Mistakes:

• Confusing Member with Book class
• Assigning book details to Loan class
• Thinking Librarian stores book info

2. Which of the following is the correct way to define a method named borrowBook inside the Member class in Python?

easy

A. def borrowBook():

B. def borrowBook(book):

C. def borrowBook(self):

D. def borrowBook(self, book):

Solution

1. Step 1: Understand method definition in Python classes

   Instance methods must have self as the first parameter to access object data.

2. Step 2: Check method parameters for borrowing a book

   The method needs the book to borrow, so it should accept a book parameter after self.

3. Final Answer:

   def borrowBook(self, book): -> Option D

4. Quick Check:

   Instance method with self and book param [OK]

Hint: Instance methods always start with self parameter [OK]

Common Mistakes:

• Omitting self parameter
• Not passing book argument
• Defining method without parameters

3. Given the following Python code snippet, what will be the output?

class Loan:
    def __init__(self, book, member):
        self.book = book
        self.member = member

loan = Loan('1984', 'Alice')
print(loan.book, loan.member)

medium

A. 1984 Alice

B. book member

C. Loan object memory address

D. Error: missing parameters

Solution

1. Step 1: Analyze the Loan class constructor

   The constructor __init__ assigns book and member to instance variables.

2. Step 2: Check the print statement output

   Printing loan.book and loan.member outputs the strings '1984' and 'Alice' separated by space.

3. Final Answer:

   1984 Alice -> Option A

4. Quick Check:

   loan.book and loan.member print values [OK]

Hint: Print instance variables to see stored values [OK]

Common Mistakes:

• Expecting object memory address output
• Confusing variable names with strings
• Assuming error due to parameters

4. Identify the error in this Python class design snippet for the Librarian class:

class Librarian:
    def __init__(self, name):
        self.name = name
    def addBook(book):
        print(f"Adding {book} to library")

medium

A. Missing self parameter in addBook method

B. Incorrect print statement syntax

C. Constructor missing return statement

D. Class name should be lowercase

Solution

1. Step 1: Check method parameters in class

   Instance methods must include self as the first parameter to access instance data.

2. Step 2: Verify addBook method signature

   addBook lacks self, so it will cause an error when called on an instance.

3. Final Answer:

   Missing self parameter in addBook method -> Option A

4. Quick Check:

   Instance methods need self param [OK]

Hint: Instance methods always start with self parameter [OK]

Common Mistakes:

• Thinking print syntax is wrong
• Expecting constructor to return value
• Believing class names must be lowercase

5. In designing a library system, which class should handle the logic to check if a book is currently loaned out before allowing a member to borrow it?

hard

A. Book

B. Member

C. Loan

D. Librarian

Solution

1. Step 1: Understand responsibilities of each class

   Book stores book info, Member represents users, Loan tracks borrow records, and Librarian manages library operations.

2. Step 2: Identify who controls borrowing rules

   The Loan class should handle checking if a book is currently loaned out before allowing borrowing, as it tracks loan records.

3. Final Answer:

   Loan -> Option C

4. Quick Check:

   Loan class tracks loan status [OK]

Hint: Loan class tracks if a book is loaned out [OK]

Common Mistakes:

• Putting borrowing logic inside Book class
• Assigning loan status check to Member
• Expecting Librarian class to enforce borrowing rules