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.

Practice

1. What is the main purpose of encapsulation in system design?

easy

A. To hide internal details and protect data from outside access

B. To make all data publicly accessible for easy modification

C. To increase the size of the system components

D. To allow direct access to all internal variables

Solution

1. Step 1: Understand encapsulation concept

   Encapsulation means hiding the internal details of a system or component so that outside code cannot directly access or change them.

2. Step 2: Identify the main goal

   The main goal is to protect data and control how it is accessed or modified, improving security and reducing errors.

3. Final Answer:

   To hide internal details and protect data from outside access -> Option A

4. Quick Check:

   Encapsulation = Hide details and protect data [OK]

Hint: Encapsulation means hiding details, not exposing them [OK]

Common Mistakes:

• Thinking encapsulation means making data public
• Confusing encapsulation with system size
• Believing encapsulation allows direct variable access

2. Which of the following is the correct way to implement encapsulation in a class?

easy

A. Make all variables public and access them directly

B. Avoid using any methods to access data

C. Use private variables and provide public getter and setter methods

D. Use global variables for all data

Solution

1. Step 1: Recall encapsulation implementation

   Encapsulation is done by making variables private so they cannot be accessed directly from outside the class.

2. Step 2: Use public methods for controlled access

   Public getter and setter methods allow controlled reading and updating of private data.

3. Final Answer:

   Use private variables and provide public getter and setter methods -> Option C

4. Quick Check:

   Private variables + public methods = Encapsulation [OK]

Hint: Private variables + public getters/setters = encapsulation [OK]

Common Mistakes:

• Making variables public defeats encapsulation
• Using global variables breaks encapsulation
• Not providing any access methods causes usability issues

3. Consider this code snippet in a system design context:

class Account {
  private balance = 1000;
  public getBalance() { return this.balance; }
  public setBalance(amount) { if(amount >= 0) this.balance = amount; }
}

const acc = new Account();
acc.setBalance(-500);
console.log(acc.getBalance());

What will be the output?

medium

A. -500

B. 1000

C. 0

D. Error

Solution

1. Step 1: Analyze setBalance method behavior

   The method only updates balance if the amount is greater than or equal to zero.

2. Step 2: Check the call with -500

   Since -500 is less than zero, the balance is not updated and remains 1000.

3. Final Answer:

   1000 -> Option B

4. Quick Check:

   Negative amount ignored, balance stays 1000 [OK]

Hint: Setter blocks negative values, so balance stays unchanged [OK]

Common Mistakes:

• Assuming balance changes to -500
• Expecting zero as default
• Thinking code throws an error

4. A developer wrote this code:

class User {
  public name;
  public setName(newName) { this.name = newName; }
}

const user = new User();
user.name = null;
console.log(user.name);

What is the problem related to encapsulation here?

medium

A. The name variable is public and can be set to invalid values directly

B. The setName method is missing

C. The class should not have any variables

D. The console.log statement is incorrect

Solution

1. Step 1: Identify variable access level

   The variable name is public, so it can be changed directly without validation.

2. Step 2: Understand encapsulation violation

   Direct access allows setting invalid values like null, bypassing any checks in setName.

3. Final Answer:

   The name variable is public and can be set to invalid values directly -> Option A

4. Quick Check:

   Public variable allows invalid direct access [OK]

Hint: Public variables can be changed without checks, breaking encapsulation [OK]

Common Mistakes:

• Thinking setName method is missing
• Believing variables should be removed
• Blaming console.log for output

5. You are designing a banking system where account balance must never be negative. Which approach best uses encapsulation and information hiding to enforce this rule?

hard

A. Make balance public and rely on users to not set negative values

B. Store balance as a global variable accessible everywhere

C. Do not provide any methods to access balance

D. Make balance private and provide a setter that only updates if amount ≥ 0

Solution

1. Step 1: Protect balance data

   Making balance private hides it from direct external changes, preventing accidental or malicious updates.

2. Step 2: Control updates via setter method

   The setter method enforces the rule by allowing updates only if the new amount is zero or positive.

3. Step 3: Avoid unsafe alternatives

   Public or global variables allow uncontrolled changes, risking negative balances and errors.

4. Final Answer:

   Make balance private and provide a setter that only updates if amount ≥ 0 -> Option D

5. Quick Check:

   Private balance + validated setter = safe encapsulation [OK]

Hint: Private data + validated setter enforces rules safely [OK]

Common Mistakes:

• Making balance public and trusting users
• Not providing access methods causes usability issues
• Using global variables breaks encapsulation