How do you model search functionality in the library system?
Fast recall
Quick revision
Core answer
Can you apply the Strategy pattern to decouple search implementation from the catalog interface, demonstrating knowledge of behavioral design patterns
Freshers hardcode multiple search methods in LibraryCatalog (searchByTitle, searchByAuthor) creating a bloated class that violates Open-Closed Principle
Mention combining criteria with Composite pattern for advanced searches like author AND genre or suggest indexing strategies for performance
Interview-ready guide
Interview answer
Searching by title, author, ISBN, or genre is the same operation with a different algorithm behind it each time, and that's the classic signal for the Strategy pattern. I'd define a SearchStrategy interface with a single search method that takes the catalog and a search term and returns matching books. Then each criterion is its own class — SearchByTitle, SearchByAuthor, SearchByISBN, SearchByGenre — each implementing that method with its own filtering logic.
The LibraryCatalog holds the books and exposes a search method that takes a SearchStrategy and delegates to it. So the catalog never needs to know how a particular search works; it just passes the call through. The big win is extensibility: when someone asks to add search by publication year, that's a brand new class implementing the interface, and I don't touch the catalog at all. That's the Open/Closed Principle.
Compare that to the naive approach, which is one search method with a long if-else or switch on a type string. Every new criterion means editing and retesting that one method, and it grows without bound.
For a real system I'd add one more point: a pure Strategy still scans the whole catalog, which is fine for an interview but slow at scale. So I'd back it with indexes — maps keyed by author or genre — so the strategy can look up rather than scan. And I'd keep the matching case-insensitive so users actually find what they're after.
For example, an ISBN strategy can perform one exact lookup in Map, while an author strategy normalizes “Joshua Bloch” and returns the set of matching book ids. Both satisfy the same search contract, but each uses an index suited to its key.
How do you model search functionality in the library system
Direct Answer
Use the Strategy pattern with a SearchCriteria interface. Implementations like SearchByTitle, SearchByAuthor, SearchByISBN, SearchByGenre encapsulate different search algorithms. LibraryCatalog accepts any SearchCriteria and delegates to its execute method. This keeps search logic decoupled and makes adding new criteria trivial.
Deep Dive & Architecture
Search begins with a query contract
The catalogue can accept a SearchQuery containing optional title, author, ISBN, and genre fields, then return matching book records. Separate strategies are useful when each search mode follows genuinely different rules; a single query object is simpler when filters are commonly combined.
Indexes avoid scanning every book
An ISBN search should use a Map<String, Book> because ISBN is an exact unique key. Author and genre searches can use maps from a normalized value to a set of book ids. A title search may normalize case and whitespace or delegate partial-text matching to a database search index. For example, searching ISBN 9780134685991 performs one map lookup, while searching author “Bloch” returns the ids stored under the normalized author key.
Results need an explicit policy
The design should state whether search returns book titles or physical BookCopy objects, how duplicates are removed, how results are sorted, and how pagination works. These decisions keep the search API stable even if its in-memory implementation is later replaced by SQL or a search service.
Common Mistakes & Pitfalls
- A growing if-else on search type — exactly what Strategy removes.
- Full linear scan every time — fine to mention, but add indexes (
Mapby author/genre) for scale. - Search logic inside
Book—Bookis data; searching is the catalog's/strategy's job. - Case-sensitive matching — use
equalsIgnoreCase/containsso users find results.
Check your understanding
Answer these without looking back at the article.
- Design a library management system. What are the key classes?
- How do you handle the book reservation system in LLD?
- How do you handle fines in the library management system?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.