Encapsulation and information hiding in LLD - System Design Exercise

Design: Encapsulation and Information Hiding in Object-Oriented Design

Focus on designing classes and interfaces demonstrating encapsulation and information hiding. Out of scope: database persistence, UI design, network communication.

Functional Requirements

FR1: Design a simple library management system where book details are protected from direct modification.

FR2: Allow users to borrow and return books through controlled methods only.

FR3: Ensure internal data like book availability and user borrowing history are not directly accessible.

FR4: Provide clear interfaces for interacting with books and users without exposing internal data structures.

Non-Functional Requirements

NFR1: System should prevent unauthorized changes to book details and user data.

NFR2: Operations like borrowing and returning books must validate rules before changing state.

NFR3: The system should be easy to maintain and extend without exposing internal implementation.

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

Key Components

Classes representing Book and User

Private fields for sensitive data

Public methods for controlled access

Access modifiers to restrict visibility

Design Patterns

Encapsulation using private and public members

Information hiding by restricting direct data access

Use of getter and setter methods with validation

Interface segregation to expose only necessary operations

Reference Architecture

Library Management System

+----------------+       +----------------+
|     User       |       |      Book      |
+----------------+       +----------------+
| - userId       |       | - bookId       |
| - name         |       | - title        |
| - borrowedBooks|<>-----| - author       |
+----------------+       | - isAvailable  |
| + borrowBook() |       +----------------+
| + returnBook() |       | + borrow()     |
+----------------+       | + return()     |
                         +----------------+

Components

Book Class

Object-Oriented Programming (any language)

Encapsulates book details with private fields and exposes borrow and return methods to control availability.

User Class

Object-Oriented Programming (any language)

Encapsulates user information and borrowed books list, provides methods to borrow and return books.

Request Flow

1. User calls borrowBook(book) method.

2. User class calls book.borrow() method.

3. Book checks if it is available internally.

4. If available, book marks itself unavailable and returns success.

5. User adds book to borrowedBooks list.

6. Return success to user.

7. For returning, similar flow with book.return() and updating user list.

Database Schema

Not applicable - focus on class design. Entities: - Book: bookId (private), title (private), author (private), isAvailable (private) - User: userId (private), name (private), borrowedBooks (private list) Relationships: - User has many borrowedBooks All fields are private to enforce encapsulation.

Scaling Discussion

Bottlenecks

Direct access to private data if encapsulation is not enforced.

Complex validation logic inside methods can grow and become hard to maintain.

Tight coupling if internal details leak through interfaces.

Solutions

Use strict access modifiers (private/protected) to enforce encapsulation.

Keep validation logic modular and separate from data storage.

Design clear interfaces that expose only necessary operations.

Apply design principles like Single Responsibility to keep classes focused.

Interview Tips

Time: Spend 10 minutes explaining encapsulation concepts and why information hiding matters. Use 15 minutes to design classes with private fields and public methods. Use last 5 minutes to discuss how this design helps maintainability and security.

Explain difference between encapsulation and information hiding.

Show how private fields protect data integrity.

Demonstrate controlled access via public methods.

Discuss benefits: easier maintenance, less bugs, better security.

Mention how this design supports future changes without breaking users.