Building a Library Management System

Hello! Welcome to your next low-level design case study.

In our last lesson, we designed a parking lot system using a structured, five-step framework. This framework is your guide to confidently navigating LLD interview questions, ensuring you cover all the critical aspects from requirements to implementation.

Today, we'll apply that same framework to another classic problem. Your learning outcome is to design a library management system with book borrowing, returns, and fine calculation. This case study will reinforce your understanding of core OOP principles, entity relationship modeling, and how to separate responsibilities within a system.

Let's quickly recall the 5-step framework we'll be using:

1. Clarify Requirements & Scope
2. Identify Core Entities & Use Cases
3. Design Classes & Interactions
4. Implement Core Logic
5. Verify & Discuss Extensions

By following these steps, you will build a robust design for the library system and further sharpen your LLD problem-solving skills.

Step 1: Clarify Requirements & Scope

As before, we start with a broad prompt: "Design a library management system." Our first job is to ask clarifying questions to establish a clear set of functional and non-functional requirements.

To understand what a good set of requirements looks like for this problem, let's consult a well-structured guide.

The process of arriving at these requirements is a dialogue. You need to probe the problem space. Let's see how this is done.

Combining these resources, we have a solid foundation. Our system needs to manage books, members, borrowing, returns, reservations, and fines.

Step 2: Identify Core Entities & Use Cases

With our requirements defined, we can now identify the "nouns" that will become our core classes and the "verbs" that will become our primary use cases.

Based on the requirements, our main entities include:

• Book, BookItem (a specific copy)
• Member, Librarian (our actors)
• Library (the main system)
• Account
• BookReservation, BookLending (or Checkout)
• Fine

The main use cases are:

• Search for a book.
• Check out a book.
• Return a book.
• Renew a book.
• Reserve a book.
• Calculate and collect fines.

To visualize how these pieces fit together, interviewers often appreciate a simple Use Case Diagram. This diagram shows the actors and how they interact with the system's functions.

Step 3: Design Classes & Interactions

Now we move to the heart of the LLD process: defining the classes, their attributes, methods, and relationships.

A. Key Design Decisions

Let's think through some of the most important design choices.

1. Book vs. BookItem:
This is a critical distinction. A Book represents the abstract concept (e.g., "Clean Code" by Robert C. Martin), which has a title, author, and ISBN. A BookItem is a specific physical copy of that book, with a unique barcode and a status (e.g., Available, Loaned). The library might have ten BookItems corresponding to one Book. This one-to-many relationship is fundamental.

2. Actor Hierarchy:
Both Member and Librarian are people who interact with the system. We can model this using inheritance. A base Person class can hold common attributes like name and address. An Account class (or a SystemUser class as shown in some designs) can extend Person to add login credentials. Finally, Member and Librarian can extend Account, adding their specific attributes and behaviors. This leverages polymorphism and follows the Liskov Substitution Principle.

3. Service-Oriented Design:
Functionality like searching, issuing books, or calculating fines can be encapsulated in dedicated service classes. For instance, a SearchService can handle all search logic, and a FineService can manage fine calculations. This adheres to the Single Responsibility Principle (SRP) and makes the system more modular and maintainable. The Member and Librarian classes would then use these services (composition) to perform their tasks.

Let's watch a detailed walkthrough of how these classes can be designed.

B. UML Class Diagram

A UML class diagram brings all these ideas together into a single blueprint. It's the most important artifact you'll produce in an LLD interview.

This diagram clearly shows:

• Inheritance: The User hierarchy.
• Composition: Library has a collection of Books and Users.
• Association: A Checkout record associates a User with a Book.
• Attributes and Methods: Key data members and functions for each class are laid out.

Step 4: Implement Core Logic

You won't be expected to write fully running code in a 45-minute interview, but you must be able to write the skeleton code for the most important operations. For our system, these are borrowing, returning, and calculating fines.

A. Borrowing, Returning, and Fine Calculation

Let's look at some clean Java code that implements these key use cases. This will demonstrate how the classes we've designed interact.

B. Focusing on the Fine Calculation

The calculateFine logic is a specific requirement of our learning outcome. Let's see how a dedicated service can handle this.

Test your understanding!

The Grokking example puts the checkForFine logic inside the Member class. The video example creates a separate FineService class. What are the pros and cons of each approach in the context of the SOLID principles?

Show answer

• checkForFine in Member Class:

  • Pro: It's simple and intuitive. A member is responsible for their fines.
  • Con: It violates the Single Responsibility Principle (SRP). The Member class is now responsible for managing member data and for the business logic of calculating fines. If the fine policy changes (e.g., different rates for different member types or books), you have to modify the Member class.

• Separate FineService Class:

  • Pro: It adheres to SRP. The FineService has one job: manage everything related to fines. This also supports the Open/Closed Principle (OCP). If you want to add a new way to calculate fines, you could implement a FineStrategy interface and inject it into the FineService, without changing the service itself. This design is more modular and extensible.
  • Con: It adds a bit more complexity with an extra class and the interaction between them.

For a robust, enterprise-level system, the FineService approach is superior. It demonstrates a deeper understanding of SOLID principles.

Step 5: Verify & Discuss Extensions

Finally, you should be able to walk the interviewer through a scenario to prove your design works and discuss how you might extend it.

A. Verifying with a Sequence Diagram

A sequence diagram is perfect for showing how objects collaborate over time to fulfill a use case.

You can use this diagram to narrate the entire process, explaining which object calls which method in what order.

B. Discussing Extensions

A great way to end is by showing you've thought about future needs.
Interviewer: "This is a great design for books. How would you extend it to handle other library items like magazines or academic journals, which have different borrowing periods and fine rates?"

Your Response:
"That's an excellent question. We can handle this elegantly using polymorphism.

1. I would introduce a LibraryItem abstract class, similar to the approach in the Library Management System - Java OOP Case Study document (LINK).
2. This LibraryItem class would have an abstract method: abstract double calculateLateFee(int daysLate);.
3. Our existing Book class would extend LibraryItem. We would also create new classes like Magazine and Journal that also extend LibraryItem.
4. Each of these subclasses would provide its own concrete implementation of the calculateLateFee method, containing its specific fine logic (e.g., $1.50/day for books, $1.00/day for magazines).
5. The rest of the system, like the Member or FineService, would continue to work with the LibraryItem interface. When they call calculateLateFee(), Java's runtime polymorphism will automatically execute the correct version of the method based on the object's actual type (whether it's a Book, Magazine, etc.). This adheres to the Open/Closed Principle, as we can add new item types without modifying the existing code that handles fine calculations."

Conclusion

Fantastic work! You have successfully applied the 5-step LLD framework to design a Library Management System.

Key Takeaways:

• Framework is Reusable: The structured approach of clarifying, identifying entities, designing classes, implementing logic, and verifying is a powerful and reusable tool for any LLD problem.
• Model the Real World: The Book vs. BookItem distinction is a crucial insight that comes from carefully modeling the real-world domain.
• Leverage OOP and SOLID: We used inheritance for actors (Person -> Member) and polymorphism for extensibility (LibraryItem hierarchy). We applied SRP by creating separate service classes (SearchService, FineService).
• Visualize Your Design: UML diagrams (Class and Sequence) are invaluable tools for clarifying your own thoughts and communicating your design to others.

In the next lesson, we will tackle our third case study: designing an elevator control system. This will introduce new challenges, particularly around state management and request scheduling, allowing you to apply your design skills to a different kind of problem.