## File: README.md

This repository contains resources to learn Low Level Design (LLD) / Object Oriented Design (OOD) and prepare for interviews. It covers OOP fundamentals, design patterns, UML, concurrency and commonly asked interview questions.

👉 For a better and more comprehensive experience, checkout the [LLD page at AlgoMaster.io](https://algomaster.io/learn/lld)

## 🧱 OOP Fundamentals
- [Classes and Objects](https://algomaster.io/learn/lld/classes-and-objects)
- [Enums](https://algomaster.io/learn/lld/enums)
- [Interfaces](https://algomaster.io/learn/lld/interfaces)
- [Encapsulation](https://algomaster.io/learn/lld/encapsulation)
- [Abstraction](https://algomaster.io/learn/lld/abstraction)
- [Inheritance](https://algomaster.io/learn/lld/inheritance)
- [Polymorphism](https://algomaster.io/learn/lld/polymorphism)

## 🔗 Class Relationships
- [Association](https://algomaster.io/learn/lld/association)
- [Aggregation](https://algomaster.io/learn/lld/aggregation)
- [Composition](https://algomaster.io/learn/lld/composition)
- [Dependency](https://algomaster.io/learn/lld/dependency)

## 🧭 Design Principles
- [DRY Principle](https://algomaster.io/learn/lld/dry)
- [YAGNI Principle](https://algomaster.io/learn/lld/yagni)
- [KISS Principle](https://algomaster.io/learn/lld/kiss)
- [SOLID Principles with Pictures](https://medium.com/backticks-tildes/the-s-o-l-i-d-principles-in-pictures-b34ce2f1e898)
- [SOLID Principles with Code](https://blog.algomaster.io/p/solid-principles-explained-with-code)

## 🧩 Design Patterns

| **Creational Patterns**                                                       | **Structural Patterns**                                         | **Behavioral Patterns**                                                               |
| ----------------------------------------------------------------------------- | --------------------------------------------------------------- | ------------------------------------------------------------------------------------- |
| [Singleton](https://algomaster.io/learn/lld/singleton)            | [Adapter](https://algomaster.io/learn/lld/adapter)     | [Iterator](https://algomaster.io/learn/lld/iterator)                         |
| [Factory Method](https://algomaster.io/learn/lld/factory-method)     | [Bridge](https://algomaster.io/learn/lld/bridge)       | [Observer](https://algomaster.io/learn/lld/observer)                         |
| [Abstract Factory](https://algomaster.io/learn/lld/abstract-factory) | [Composite](https://algomaster.io/learn/lld/composite) | [Strategy](https://algomaster.io/learn/lld/strategy)                         |
| [Builder](https://algomaster.io/learn/lld/builder)                   | [Decorator](https://algomaster.io/learn/lld/decorator) | [Command](https://algomaster.io/learn/lld/command)                           |
| [Prototype](https://algomaster.io/learn/lld/prototype)               | [Facade](https://algomaster.io/learn/lld/facade)       | [State](https://algomaster.io/learn/lld/state)                               |
|                                                                               | [Flyweight](https://algomaster.io/learn/lld/flyweight) | [Template Method](https://algomaster.io/learn/lld/template-method)           |
|                                                                               | [Proxy](https://algomaster.io/learn/lld/proxy)         | [Visitor](https://algomaster.io/learn/lld/visitor)                           |
|                                                                               |                                                                 | [Mediator](https://algomaster.io/learn/lld/mediator)                         |
|                                                                               |                                                                 | [Memento](https://algomaster.io/learn/lld/memento)                           |
|                                                                               |                                                                 | [Chain of Responsibility](https://algomaster.io/learn/lld/chain-of-responsibility) |

## 🗂️ UML
- [Class Diagram](https://algomaster.io/learn/lld/class-diagram)
- [Use Case Diagram](https://algomaster.io/learn/lld/use-case-diagram)
- [Sequence Diagram](https://algomaster.io/learn/lld/sequence-diagram)
- [Activity Diagram](https://algomaster.io/learn/lld/activity-diagram)
- [State Machine Diagram](https://algomaster.io/learn/lld/state-machine-diagram)

## ⏱️ Concurrency and Multi-threading Concepts
### Concurrency 101
- [Introduction to Concurrency](https://algomaster.io/learn/concurrency-interview/introduction-to-concurrency)
- [Concurrency vs Parallelism](https://algomaster.io/learn/concurrency-interview/concurrency-vs-parallelism)
- [Processes vs Threads](https://algomaster.io/learn/concurrency-interview/processes-vs-threads)
- [Thread Lifecycle and States](https://algomaster.io/learn/concurrency-interview/thread-lifecycle-and-states)
- [Race Conditions and Critical Sections](https://algomaster.io/learn/concurrency-interview/race-conditions-and-critical-sections)
### Synchronization Primitives
- [Mutex (Mutual Exclusion)](https://algomaster.io/learn/concurrency-interview/mutex)
- [Semaphores](https://algomaster.io/learn/concurrency-interview/semaphores)
- [Condition Variables](https://algomaster.io/learn/concurrency-interview/condition-variables)
- [Coarse-grained vs Fine-grained Locking](https://algomaster.io/learn/concurrency-interview/coarse-vs-fine-grained-locking)
- [Reentrant Locks](https://algomaster.io/learn/concurrency-interview/reentrant-locks)
- [Try-Lock and Timed Locking](https://algomaster.io/learn/concurrency-interview/try-lock-and-timed-locking)
- [Compare-and-Swap (CAS)](https://algomaster.io/learn/concurrency-interview/compare-and-swap)
### Concurrency Challenges
- [Deadlock](https://algomaster.io/learn/concurrency-interview/deadlock)
- [Livelock](https://algomaster.io/learn/concurrency-interview/livelock)
### Concurrency Patterns
- [Signaling Pattern](https://algomaster.io/learn/concurrency-interview/signaling-pattern)
- [Thread Pool Pattern](https://algomaster.io/learn/concurrency-interview/thread-pool-pattern)
- [Producer-Consumer Pattern](https://algomaster.io/learn/concurrency-interview/producer-consumer-pattern)
- [Reader-Writer Pattern](https://algomaster.io/learn/concurrency-interview/reader-writer-pattern)

## ✅ [How to Answer a LLD Interview Problem](https://blog.algomaster.io/p/how-to-answer-a-lld-interview-problem)


## 💻 Low Level Design Interview Problems
### Easy Problems

- [Design Parking Lot](problems/parking-lot.md)
- [Design Stack Overflow](problems/stack-overflow.md)
- [Design a Vending Machine](problems/vending-machine.md)
- [Design Logging Framework](problems/logging-framework.md)
- [Design Traffic Signal Control System](problems/traffic-signal.md)
- [Design Coffee Vending Machine](problems/coffee-vending-machine.md)
- [Design a Task Management System](problems/task-management-system.md)

### Medium Problems

- [Design ATM](problems/atm.md)
- [Design LinkedIn](problems/linkedin.md)
- [Design LRU Cache](problems/lru-cache.md)
- [Design Tic Tac Toe Game](problems/tic-tac-toe.md)
- [Design Pub Sub System](problems/pub-sub-system.md)
- [Design an Elevator System](problems/elevator-system.md)
- [Design Car Rental System](problems/car-rental-system.md)
- [Design an Online Auction System](problems/online-auction-system.md)
- [Design Hotel Management System](problems/hotel-management-system.md)
- [Design a Digital Wallet Service](problems/digital-wallet-service.md)
- [Design Airline Management System](problems/airline-management-system.md)
- [Design a Library Management System](problems/library-management-system.md)
- [Design a Social Network like Facebook](problems/social-networking-service.md)
- [Design Restaurant Management System](problems/restaurant-management-system.md)
- [Design a Concert Ticket Booking System](problems/concert-ticket-booking-system.md)

### Hard Problems

- [Design CricInfo](problems/cricinfo.md)
- [Design Splitwise](problems/splitwise.md)
- [Design Chess Game](problems/chess-game.md)
- [Design a Snake and Ladder game](problems/snake-and-ladder.md)
- [Design Ride-Sharing Service like Uber](problems/ride-sharing-service.md)
- [Design Course Registration System](problems/course-registration-system.md)
- [Design Movie Ticket Booking System](problems/movie-ticket-booking-system.md)
- [Design Online Shopping System like Amazon](problems/online-shopping-service.md)
- [Design Online Stock Brokerage System](problems/online-stock-brokerage-system.md)
- [Design Music Streaming Service like Spotify](problems/music-streaming-service.md)
- [Design Online Food Delivery Service like Swiggy](problems/food-delivery-service.md)

## ⏱️ Concurrency and Multi-threading Problems

- [Print FooBar Alternately](https://algomaster.io/learn/concurrency-interview/print-foobar-alternately)
- [Print Zero Even Odd](https://algomaster.io/learn/concurrency-interview/print-zero-even-odd)
- [Fizz Buzz Multithreaded](https://algomaster.io/learn/concurrency-interview/fizz-buzz-multithreaded)
- [Building H2O Molecule](https://algomaster.io/learn/concurrency-interview/building-h2o)
- [Design Thread-Safe Cache with TTL](https://algomaster.io/learn/concurrency-interview/design-thread-safe-cache-with-ttl)
- [Design Concurrent HashMap](https://algomaster.io/learn/concurrency-interview/design-concurrent-hashmap)
- [Design Thread-Safe Blocking Queue](https://algomaster.io/learn/concurrency-interview/design-thread-safe-blocking-queue)
- [Design Concurrent Bloom Filter](https://algomaster.io/learn/concurrency-interview/design-concurrent-bloom-filter)
- [Multi-threaded Merge Sort](https://algomaster.io/learn/concurrency-interview/multi-threaded-merge-sort)

## 📇 Courses
- [Master LLD Interviews - AlgoMaster.io](https://algomaster.io/learn/lld/course-introduction)
- [Master Concurrency Interviews - AlgoMaster.io](https://algomaster.io/learn/concurrency-interview)

## 📚 Books
- [Head First Design Patterns](https://www.amazon.in/dp/9385889753)
- [Clean Code](https://www.amazon.in/dp/B001GSTOAM)
- [Refactoring: Improving the Design of Existing Code](https://www.amazon.in/dp/0134757599)

## 📩 Newsletter
- [AlgoMaster Newsletter](https://blog.algomaster.io/)

## Additional resources
- [Coursera - Object-Oriented Design](https://www.coursera.org/learn/object-oriented-design)
- [Coursera - Design Patterns](https://www.coursera.org/learn/design-patterns)
- [Github - Awesome Design Patterns](https://github.com/DovAmir/awesome-design-patterns)

## 🤝 Contributing
Contributions are welcome! If you'd like to add a new problem, improve existing content, or fix errors:
1. Fork the repository
2. Create a feature branch: `git checkout -b feature/your-feature-name`
3. Commit your changes: `git commit -m 'Add some feature'`
4. Push to the branch: `git push origin feature/your-feature-name`
5. Submit a pull request

Please make sure to update Readme files and documentation as appropriate.

---

---

## File: design-patterns/python/adapter/README.md

# Adapter Design Pattern in Python

## Problem Statement

The Adapter pattern allows incompatible interfaces to work together. It acts as a bridge between two incompatible interfaces by converting the interface of one class into another interface that clients expect.

---

## Core Components

### 1. Target Interface (PaymentProcessor)
```python
class PaymentProcessor(ABC):
    @abstractmethod
    def process_payment(self, amount: float, currency: str) -> None:
        pass
```

### 2. Adaptee (LegacyGateway)
```python
class LegacyGateway:
    def make_payment(self, currency: str, amount: float) -> None:
        # Legacy payment processing logic
        pass
```

### 3. Adapter (LegacyGatewayAdapter)
```python
class LegacyGatewayAdapter(PaymentProcessor):
    def __init__(self, legacy_gateway: LegacyGateway):
        self.legacy_gateway = legacy_gateway

    def process_payment(self, amount: float, currency: str) -> None:
        self.legacy_gateway.make_payment(currency, amount)
```

### 4. Client (CheckoutService)
```python
class CheckoutService:
    def __init__(self, payment_processor: PaymentProcessor):
        self.payment_processor = payment_processor

    def checkout(self, amount: float, currency: str) -> None:
        self.payment_processor.process_payment(amount, currency)
```

---

## Example Usage

```python
def main():
    # Using the in-house payment processor
    in_house_processor = InHousePaymentProcessor()
    checkout_service = CheckoutService(in_house_processor)
    checkout_service.checkout(100, "USD")

    # Using the legacy payment gateway through adapter
    legacy_processor = LegacyGatewayAdapter(LegacyGateway())
    checkout_service = CheckoutService(legacy_processor)
    checkout_service.checkout(100, "USD")
```

---

## Benefits

1. **Single Responsibility Principle:**
   - Separates the interface conversion logic from the business logic
   - Each class has a single responsibility

2. **Open/Closed Principle:**
   - New adapters can be added without modifying existing code
   - System remains open for extension but closed for modification

3. **Reusability:**
   - Existing classes can be reused with new interfaces
   - Reduces code duplication

4. **Flexibility:**
   - Multiple adapters can be created for different purposes
   - Easy to switch between different implementations

---

## When to Use

1. **When integrating incompatible interfaces:**
   - Working with legacy systems
   - Using third-party libraries
   - Migrating between different versions

2. **When creating a reusable class:**
   - The class needs to work with unrelated classes
   - The class needs to work with classes that don't have compatible interfaces

3. **When implementing multiple interfaces:**
   - A class needs to implement multiple interfaces
   - Different clients need different views of the same class

---

## Best Practices

1. **Keep it Simple:**
   - Adapters should be simple and focused
   - Avoid adding unnecessary functionality

2. **Documentation:**
   - Clearly document the purpose of the adapter
   - Explain the conversion logic

3. **Testing:**
   - Test the adapter thoroughly
   - Ensure it works with both the target and adaptee

4. **Error Handling:**
   - Handle conversion errors gracefully
   - Provide meaningful error messages

---

## Common Pitfalls

1. **Over-engineering:**
   - Creating adapters when not needed
   - Adding unnecessary complexity

2. **Tight Coupling:**
   - Creating dependencies between adapters
   - Making the system less flexible

3. **Performance Issues:**
   - Adding too many layers of adaptation
   - Impacting system performance

---

---

## File: design-patterns/python/README.md

# Design Patterns in Python

This directory contains Python implementations of various design patterns, following the same examples and structure as the Java implementations.

## Implemented Patterns

### Creational Patterns
- **[Adapter Pattern](adapter/)** - Convert interface of a class into another interface
- **[Factory Method Pattern](factory/)** - Create objects without specifying exact classes
- **[Builder Pattern](builder/)** - Construct complex objects step by step
- **[Singleton Pattern](singleton/)** - Ensure only one instance of a class exists

### Behavioral Patterns
- **[Observer Pattern](observer/)** - Define one-to-many dependency between objects
- **[Strategy Pattern](strategy/)** - Define family of algorithms and make them interchangeable

### Structural Patterns
- **Abstract Factory Pattern** - Create families of related objects
- **Bridge Pattern** - Separate abstraction from implementation
- **Composite Pattern** - Compose objects into tree structures
- **Decorator Pattern** - Add behavior to objects dynamically
- **Facade Pattern** - Provide simplified interface to complex subsystem
- **Flyweight Pattern** - Minimize memory usage with shared objects
- **Proxy Pattern** - Provide placeholder/surrogate for another object

### Additional Behavioral Patterns
- **Chain of Responsibility** - Pass requests along handler chain
- **Command Pattern** - Encapsulate requests as objects
- **Iterator Pattern** - Access elements sequentially without exposing structure
- **Mediator Pattern** - Define how objects interact with each other
- **Memento Pattern** - Capture and restore object state
- **State Pattern** - Allow object to alter behavior when state changes
- **Template Method Pattern** - Define skeleton of algorithm in base class
- **Visitor Pattern** - Define new operations without changing classes

## Running the Examples

Each pattern directory contains demo files that can be run independently:

```bash
# Run adapter pattern demo
python -m design-patterns.python.adapter.ecommerce_app

# Run factory pattern demo
python -m design-patterns.python.factory.factory_method_demo

# Run builder pattern demo
python -m design-patterns.python.builder.http_app_builder

# Run singleton pattern demo
python -m design-patterns.python.singleton.singleton_demo

# Run observer pattern demo
python -m design-patterns.python.observer.fitness_app_observer_demo

# Run strategy pattern demo
python -m design-patterns.python.strategy.ecommerce_app_demo
```

## Key Features

- **Same Examples**: Uses identical examples as Java implementations for consistency
- **Pythonic Code**: Follows Python conventions and best practices
- **Type Hints**: Includes type annotations for better code clarity
- **Separate Files**: Each class is in its own file for better organization
- **Abstract Base Classes**: Uses ABC for interfaces and abstract classes
- **Documentation**: Comprehensive docstrings and comments

## Pattern Structure

Each pattern follows this structure:
```
pattern_name/
├── __init__.py
├── interface_or_abstract.py      # Abstract base classes/interfaces
├── concrete_implementations.py   # Concrete classes
├── context_or_client.py          # Context classes or clients
├── demo.py                       # Demonstration of the pattern
└── README.md                     # Pattern-specific documentation
```

## Design Principles Demonstrated

- **Open/Closed Principle**: Open for extension, closed for modification
- **Dependency Inversion**: Depend on abstractions, not concretions
- **Single Responsibility**: Each class has one reason to change
- **Composition over Inheritance**: Favor object composition
- **Encapsulation**: Hide implementation details behind interfaces

## Contributing

When adding new patterns or modifying existing ones:
1. Follow the existing file structure and naming conventions
2. Include comprehensive type hints
3. Add detailed docstrings
4. Create meaningful demo examples
5. Maintain consistency with Java implementations
6. Include README documentation for each pattern

---

## File: oop/rust/abstraction/README.md

# Abstraction in Rust

**Abstraction** is the design pattern of hiding complex implementation details and exposing only the necessary functionality to the user.

> **Simple Definition:** "Show what it does, hide how it does it."

---

## 🏗️ Prerequisites: The Building Blocks
Before understanding Abstraction in Rust, we must understand two fundamental concepts that replace "Classes" in other languages: **Structs** and **Traits**.

### 1. What is a Struct?
In Java/C++, a Class holds both data and methods. In Rust, data is separated.
A **Struct** is strictly for holding **Data**. It has no behavior on its own.

**Example:**
```rust
// Just data. No logic here.
struct CoffeeMachine {
    water_level: u32,
    beans: u32,
}
```

### 2. What is a Trait?
A **Trait** is Rust's version of an **Interface**. It defines **Behavior**.
It tells us *what* functionality an object must provide, but not *how* it does it.

**Example:**
```rust
// This is the "Contract" or "Interface"
trait Brewable {
    fn make_coffee(&self); // abstract method (no body)
}
```

### 3. What is `impl`?
The `impl` keyword is the glue. It implements the **Trait** (Behavior) for a specific **Struct** (Data).

---

## ☕ Abstraction: The Real-World Example
Let's apply these concepts to build a **Coffee Machine**.

### The Problem (Without Abstraction)
If we don't use abstraction, the user has to manually handle the machine's internal parts. This is dangerous and complex.

```rust
let mut machine = CoffeeMachine { water: 0, beans: 0 };

// BAD: User has to know how the machine works internally!
machine.water = 100;       // User manually filling water?
machine.beans = 50;        // User manually loading beans?
machine.grind_beans();     // User manually starting the grinder?
// This is too complex for a normal user.
```

### The Solution (With Abstraction)
We want to hide the grinding and heating logic. The user should only see one simple button: `brew()`.

#### Step 1: Define the Abstraction (The Interface)
We create a public Trait. This is the **only** thing the user needs to understand.

```rust
// PUBLIC: The user sees this.
pub trait CoffeeMaker {
    fn add_ingredients(&mut self);
    fn press_button(&mut self);
}
```

#### Step 2: Implement the Hidden Logic
We hide the complex steps (`grind_beans`, `heat_water`) inside private helper methods. The user cannot call these directly.

```rust
pub struct PremiumMachine {
    water: u32,
    beans: u32,
}

impl PremiumMachine {
    // PRIVATE: Internal logic (Hidden details)
    fn grind_beans(&self) {
        println!("Grinding beans... 🚜");
    }

    fn heat_water(&self) {
        println!("Heating water... 🔥");
    }
}

// CONNECTING THEM: Implementing the Public Trait
impl CoffeeMaker for PremiumMachine {
    fn add_ingredients(&mut self) {
        self.water = 100;
        self.beans = 50;
    }

    fn press_button(&mut self) {
        // The abstraction happens here!
        // One simple call triggers complex internal logic.
        self.grind_beans();
        self.heat_water();
        println!("Coffee is ready! ☕");
    }
}
```

---

## 🆚 Comparison: Rust vs. OOP Languages

Rust handles abstraction differently than Java or Python because it emphasizes **memory safety** and **separation of concerns**.

| Feature | Java / C++ / Python | Rust |
| :--- | :--- | :--- |
| **Container** | `Class` (Data + Methods together) | `Struct` (Data) + `impl` (Methods) separated |
| **Interface** | `interface` or `abstract class` | `trait` |
| **Hiding Data** | `private` / `protected` keywords | Struct fields are **private by default** to other modules |
| **Override** | `@Override` annotation | Explicit implementation of Trait methods |

---

## 🧠 Why is this useful?
1.  **Safety:** The user cannot accidentally change the `water_level` to a wrong value because the field is private.
2.  **Simplicity:** The user doesn't need to know *how* to grind beans; they just press the button.
3.  **Flexibility:** We can swap the `PremiumMachine` with a `CheapMachine`, and as long as they both implement the `CoffeeMaker` trait, the user code doesn't change.

---

## File: oop/rust/aggregation/README.md

# Aggregation in Rust (References & Lifetimes)

## Introduction

**Aggregation** is a specific type of association in Object-Oriented Programming (OOP) representing a **"Has-A"** relationship.
* **Crucial Distinction:** The lifecycle of the contained object (Child) is **independent** of the container object (Parent).
* **In plain English:** If the University closes down (is destroyed), the Professors do not die; they go home.

**Does Rust support Aggregation?**
Yes, but it is stricter than Java. In Rust, Aggregation is implemented using **References (`&T`)** and **Lifetimes (`'a`)**.



---

## **1. The Core Concept: Borrowing vs. Owning**

To understand Aggregation, you must understand Rust's memory model:

1.  **Composition (Strong):** The Parent **OWNS** the Child.
    * *Rust:* `struct Parent { child: Child }`
    * *Result:* If Parent dies, Child dies immediately.
2.  **Aggregation (Weak):** The Parent **BORROWS** the Child.
    * *Rust:* `struct Parent<'a> { child: &'a Child }`
    * *Result:* Parent holds a pointer. If Parent dies, the Child is unaffected because the Parent never owned it.

---

## **2. The "Lifetime" Problem (`'a`)**

This is the most unique part of Rust. If a struct holds a reference, the borrow checker will reject invalid lifetimes at compile time:
> *"What if the University holds a pointer to a Professor, but the Professor has already been deleted? The University would be pointing to garbage memory!"*

To prevent this, we use **Lifetime Annotations (`'a`)**.

```rust
// <'a> reads as: "This struct lives for a duration called 'a"
struct University<'a> {
    // This reference must live AT LEAST as long as 'a
    professor: &'a Professor,
}

```

**What this tells the compiler:**
*"I promise that the `Professor` will stay alive longer than (or at least as long as) the `University`."*

---

## **3. Code Implementation**

### **Step 1: The Independent Object**

The `Professor` owns its own data. It doesn't know about the University.

```rust
struct Professor {
    name: String,
}

```

### **Step 2: The Container (With Lifetimes)**

The `University` holds a **Reference** (`&`) to the Professor.

```rust
struct University<'a> {
    name: String,
    // Aggregation: We borrow the professor
    staff: Vec<&'a Professor>,
}

```

### **Step 3: Usage**

```rust
fn main() {
    // 1. Create the Child (Owner)
    let prof = Professor { name: "Dr. Smith".into() };

    {
        // 2. Create the Parent (Borrower)
        let mut uni = University { 
            name: "MIT".into(), 
            staff: vec![&prof] // Borrowing here
        }; 
        
        // uni is destroyed here...
    } 

    // 3. PROOF OF AGGREGATION:
    // The Professor is still alive!
    println!("{} is currently unemployed but alive.", prof.name);
}

```

---

## **4. Advanced: Shared Ownership (`Rc<T>`)**

Sometimes, you don't know who will die first. Maybe the Professor belongs to 3 Universities at once.
For this, Rust uses **Reference Counting (`Rc`)**.

* **`Rc<T>`**: A smart pointer that keeps track of how many owners exist.
* The object is only deleted when the **count reaches 0**.

```rust
use std::rc::Rc;

struct Company {
    // Shared Ownership Aggregation
    employee: Rc,
}

```

---

## **Comparison: Aggregation vs Composition**

| Feature | Aggregation (Weak) | Composition (Strong) |
| --- | --- | --- |
| **Relationship** | **"Uses a"** / **"Has access to"** | **"Consists of"** |
| **Rust Syntax** | `&'a T` (Reference) | `T` (Direct Value) |
| **Ownership** | **Borrowed** (Parent does not own) | **Owned** (Parent owns Child) |
| **Lifecycle** | **Independent** (Child survives Parent) | **Dependent** (Child dies with Parent) |
| **Drop Rule** | Dropping Parent **does nothing** to Child. | Dropping Parent **drops** Child. |

---

## 📚 New Terminology

| Term | Detailed Explanation |
| --- | --- |
| **Lifetime (`'a`)** | A generic parameter that restricts how long a Reference is valid. It ensures a struct never points to dead memory. |
| **Borrow Checker** | The part of the Rust compiler that enforces Aggregation rules. It ensures the "Child" lives longer than the "Parent". |
| **Dangling Pointer** | A pointer that points to invalid memory. Rust's Aggregation rules exist specifically to prevent this. |
| **`Vec<&T>`** | A Vector that stores *addresses* of objects, not the objects themselves. |

---

## File: oop/rust/association/README.md

# Association in Rust (Shared Ownership & Weak Pointers)

## Introduction

**Association** represents a **"Knows-a"** or **"Uses-a"** relationship. Unlike Composition (where objects die together) or Aggregation (where one borrows the other), Association often implies that multiple objects interact as peers.

**The Rust Challenge:**
In Java, a `Teacher` can hold a list of `Student` objects, and those same `Student` objects can be held by another `Teacher`.
In Rust, a value can strictly have **only one owner**.

To allow multiple Teachers to "know" the same Student, we must use **Shared Ownership**.

---

## **1. Unidirectional Association (Shared Ownership)**

When multiple parents need to access the same child, we use **`Rc<T>` (Reference Counting)**.
* `Rc` keeps track of how many things are pointing to the data.
* The data is only deleted when the count hits 0.

### **Example: Many Teachers, One Student**
Teacher A and Teacher B both teach "Alice". They both need to point to the *same* Alice in memory.

```rust
use std::rc::Rc;

struct Student { name: String }

struct Teacher {
    name: String,
    // Rc allows multiple teachers to own the same student
    students: Vec<Rc<Student>>, 
}

```

---

## **2. Bidirectional Association (The "Cycle" Problem)**

This is the hardest concept in Rust OOP.
If a `Library` owns a `Book` (`Rc`), and the `Book` owns the `Library` (`Rc<Library>`), the Reference Count for both will **never reach zero**.

1. Library waits for Book to die.
2. Book waits for Library to die.
3. **Result:** Memory Leak.

### **The Solution: Weak Pointers (`Weak<T>`)**

To fix this, the Child (Book) must hold a **Weak Reference** to the Parent (Library).

* **Strong Reference (`Rc`)**: "I own this. Don't delete it."
* **Weak Reference (`Weak`)**: "I point to this, but I don't own it. If it gets deleted, I'll just point to nothing."

---

## **3. Implementation Details (RefCell)**

In Association, we often need to modify an object (like adding a student to a teacher) even though it is shared. Rust doesn't allow mutating `Rc` data directly.
We use **`RefCell<T>`** for interior mutability. It enforces borrowing rules at **runtime**, which allows mutation through shared references but can panic if you violate the rules.

### **The Pattern for Bidirectional Association**

* **Parent:** Holds `Rc<RefCell<Child>>` (Strong ownership, Mutable).
* **Child:** Holds `Weak<RefCell>` (Weak link, Mutable).

---

## 📚 New Terminology (Advanced)

| Term | Java Equivalent | Detailed Explanation |
| --- | --- | --- |
| **`Rc<T>`** | Shared Reference | "Reference Counted". Allows multiple parts of code to own the same data in the Heap. |
| **`Weak<T>`** | Weak Reference | A pointer that does *not* increase the reference count. Used to break infinite loops (cycles) in bidirectional relationships. |
| **`RefCell<T>`** | N/A (Magic) | "Interior Mutability". Allows you to modify data even if you only have an immutable reference to it. Essential for linked data structures. |
| **`upgrade()`** | Checking for null | The method used to convert a `Weak` pointer into a real `Rc`. It returns `None` if the parent object has already been destroyed. |

---

## File: oop/rust/classes_and_objects/README.md

# Classes and Objects

Classes and objects form the foundation of Object-Oriented Programming (OOP).

## What is a Class?

In traditional OOP languages (like Java/C++), a **Class** is a blueprint that bundles data (attributes) and behavior (methods) together.

**Rust is different.** It separates these two concepts:
1.  **Data** is defined in a `struct`.
2.  **Behavior** is defined in an `impl` (implementation) block.

### Defining a Class (Struct + Impl) in Rust

To define the equivalent of a class in Rust, we use the `struct` keyword for the data layout and the `impl` keyword to define methods.

Here's the `Car` example translated to idiomatic Rust:

```rust
// 1. The Blueprint (Data only)
// We use 'pub' to make the struct and fields accessible to other modules.
pub struct Car {
    // Attributes
    pub color: String,
    pub make: String,
    pub model: String,
    pub year: u32,
}

// 2. The Behavior (Methods)
impl Car {
    // Constructor-like function (Associated Function)
    // Rust does not have a 'new' keyword. We create a static function typically named 'new'.
    pub fn new(color: String, make: String, model: String, year: u32) -> Self {
        Car {
            color, // Shorthand initialization (same as color: color)
            make,
            model,
            year,
        }
    }

    // Method to display car details
    // '&self' is a reference to the current object instance (like 'this' in Java)
    pub fn display_info(&self) {
        println!("Car Make: {}", self.make);
        println!("Car Model: {}", self.model);
        println!("Car Year: {}", self.year);
        println!("Car Color: {}", self.color);
    }
}
```

### 🧠 New Rust Terminology
* **`struct`**: Defines the "shape" of the object (the fields).
* **`impl`**: A block where we define functions and methods for a specific struct.
* **`&self`**: A reference to the instance itself. It means "read-only access to my own data". It is equivalent to `this` in Java.
* **Associated Function (`new`)**: Functions defined inside `impl` that do **not** take `self`. They are like `static` methods in Java. We use them as constructors.

---

## What is an Object?

An object is an **instance** of a struct. When you create an instance, you are allocating memory for that specific blueprint and filling it with real data.

### Creating Objects in Rust

In Rust, we don't use the `new` keyword to instantiate. Instead, we call the associated function we created (`Car::new`) or initialize the struct directly.

Here's how you can instantiate objects from the `Car` struct:

```rust
fn main() {
    // Creating an object (Instance) of the Car struct
    // We use "::" to call static methods (associated functions)
    // Note: We use .to_string() because "Red" is a string slice (&str), 
    // but our Struct expects an owned String.
    let car1 = Car::new(
        "Red".to_string(), 
        "Toyota".to_string(), 
        "Corolla".to_string(), 
        2020
    );

    let car2 = Car::new(
        "Blue".to_string(), 
        "Ford".to_string(), 
        "Mustang".to_string(), 
        2021
    );

    // Displaying information of each car
    // We use "." to call instance methods
    car1.display_info();
    println!("-----------------");
    car2.display_info();
}
```

### Key Differences from Java/Go
1.  **Instantiation**: No `new Car(...)`. We call `Car::new(...)` which is just a normal function we wrote.
2.  **Reference**: Variables (`car1`) **own** the data by default. In Java, variables are just references (pointers).
3.  **Strings**: We use `.to_string()` because string literals (`"Red"`) are string slices (`&str`), but our struct wants an owned `String`.


---

## 💡 Why Rust prefers Structs over Classes?

If you are coming from Java or C++, you might wonder: *"Why didn't Rust just add Classes?"*

The answer lies in **Composition over Inheritance**.

### 1. The "Banana in the Jungle" Problem
In traditional OOP (Classes), you often create deep inheritance hierarchies (`Animal` -> `Mammal` -> `Dog`).
Joe Armstrong (creator of Erlang) famously said:

> "The problem with object-oriented languages is they’ve got all this implicit environment that they carry around with them. **You wanted a banana but what you got was a gorilla holding the banana and the entire jungle.**"

In Rust:
* **Structs** are just data (The Banana).
* **Traits** are just behavior (Eating).
* You don't inherit the "Gorilla" just to get the "Banana."

### 2. No "Diamond Problem"
In languages like C++, allowing a class to inherit from two parents leads to conflicts (The Diamond Problem). Rust avoids this entirely because **Structs cannot inherit from other Structs**. You strictly use **Traits** (Interfaces) to share behavior, which is much cleaner and safer.

### 3. Better Memory Control
* **Classes** (in Java/Python) are usually references (pointers) to memory on the Heap. This is slower and causes "Garbage Collection" pauses.
* **Structs** in Rust are values; they can live on the stack or heap depending on how you store them (`Box`, `Rc`, etc.). Some fields (like `String`) include heap pointers, so layout depends on the data you put inside.

### Summary
Rust replaces **"Is-A"** relationships (Inheritance) with **"Has-A"** and **"Can-Do"** relationships (Composition and Traits).

* **Bad (OOP):** A `Car` **is a** `Vehicle`. (Forces rigid hierarchy)
* **Good (Rust):** A `Car` **has** `Engine` data (Struct) and **can** `drive` (Trait).

---

## File: oop/rust/composition/README.md

# Composition in Rust (Ownership & Embedding)

## Introduction

**Composition** is a fundamental Object-Oriented Programming (OOP) principle that represents a **"Has-A"** relationship. It allows complex objects to be built from simpler ones.

In Rust, Composition is not just a design choice; it is the **primary way** to build data structures since Rust does not support Inheritance (`extends`).

**The Core Rule of Composition in Rust:**
When Struct A contains Struct B, **A owns B**.
* They share the same lifecycle.
* They share the same memory region.
* When A is dropped (freed), B is automatically dropped.

## **What is Composition?**

Composition is when one struct embeds another struct as a field.

### **Example: A Car and its Components**

In this example, a `Car` is composed of an `Engine`, `Wheels`, and `Transmission`.
Unlike Aggregation (where we used references `&`), here we use the concrete types directly. This means the `Car` takes full **ownership** of these components.

```rust
struct Engine { horsepower: u32 }

struct Car {
    // Direct Composition (Ownership)
    // The Engine actually lives INSIDE the Car struct in memory.
    engine: Engine, 
    model: String,
}

```

### **Memory Layout Difference**

* **Java (Reference):** `Car` -> (pointer) -> `Engine` (Heap)
* **Rust (Composition):** `Car` [ `Engine` data ... `model` data ] (Stack or Heap, but contiguous)

---

## **Why Prefer Composition Over Inheritance?**

Since Rust does not have Inheritance, Composition is the standard. However, even in languages that do have Inheritance, Composition is preferred because:

1. **Flexibility:** You can swap components (e.g., change a `GasEngine` to an `ElectricEngine`) without changing the `Car` class hierarchy.
2. **Encapsulation:** The wrapper (`Car`) controls exactly how the inner objects (`Engine`) are accessed. It can hide dangerous methods.
3. **Loose Coupling:** The `Car` doesn't need to know the internal details of how `Engine` works; it just calls public methods.

---

## **Composition with Traits (Polymorphism)**

To achieve the flexibility of Java interfaces (e.g., swapping different engine types), Rust uses **Trait Objects** inside `Box`.

Since different engines (Petrol vs Diesel) might have different sizes in memory, we cannot compose them directly on the stack if we want to swap them dynamically. We must put them in a `Box` (Pointer).

```rust
trait Engine {
    fn start(&self);
}

struct PetrolEngine;
impl Engine for PetrolEngine { ... }

struct Car {
    // Box<dyn Engine> allows us to hold ANY struct that implements Engine
    engine: Box<dyn Engine>,
}

```

---

## **Composition vs Aggregation (The "Drop" Difference)**

The most important detail in Rust is **Lifecycle**.

| Feature | Composition (Strong) | Aggregation (Weak) |
| --- | --- | --- |
| **Rust Syntax** | `struct A { b: B }` | `struct A<'a> { b: &'a B }` |
| **Ownership** | **Owned** (A owns B) | **Borrowed** (A borrows B) |
| **Memory** | B is stored *inside* A. | B is stored elsewhere; A points to it. |
| **Destruction** | If A dies, **B dies too.** | If A dies, **B lives on.** |

---

## 📚 New Terminology

| Term | Explanation |
| --- | --- |
| **Ownership** | The Rust rule that says a value can only have one owner. In composition, the container is the owner. |
| **`Box<T>`** | A smart pointer that stores data on the Heap. Required when composing Dynamic Trait Objects (`dyn Trait`) because their size is unknown at compile time. |
| **Contiguous Memory** | In Rust composition, fields are stored side-by-side in memory. This improves CPU cache performance compared to Java's scattered pointers. |
| **Delegate** | A pattern where the wrapper struct (Car) calls a method on the inner struct (Engine). `car.start()` simply calls `self.engine.start()`. |

---

## File: oop/rust/encapsulation/README.md

# Encapsulation in Rust (Modules & Visibility)

## Introduction

**Encapsulation** is one of the four fundamental principles of Object-Oriented Programming (OOP). It is the practice of **bundling data (variables) and methods** into a single unit while restricting direct access to the internal details.

**Does Rust support Encapsulation?**
Yes, but it works differently than Java.
1.  **Java:** Uses classes and access modifiers (`private`, `protected`, `public`) to hide data.
2.  **Rust:** Uses **Modules** (`mod`) and the `pub` keyword. Encapsulation boundaries are set at the *Module* level, not the *Struct* level.

## **What is Encapsulation?**

Encapsulation means **wrapping** data and code together and restricting access.

### **Key Benefits of Encapsulation**
-   **Data Protection**: Prevents external code from corrupting internal state (e.g., negative bank balance).
-   **Modularity**: Changes to internal logic (like how interest is calculated) don't break the code that uses it.
-   **Interface Clarity**: Users only interact with `pub` methods, ignoring the complex details inside.

---

## **Encapsulation Using Visibility Modifiers (`pub`)**

In Java, you have `private`, `protected`, `public`, and package-private.
In Rust, everything is **private by default**.

-   **Private (Default):** Accessible only within the current module (and its sub-modules).
-   **`pub`:** Accessible from outside the module.
-   **`pub(crate)`:** Accessible anywhere inside the same project (crate), but not by external users.

### **Example: Encapsulation with Modules**

```rust
// We define a module to create a privacy boundary
mod bank {
    pub struct BankAccount {
        pub owner: String, // Public: Anyone can read/write
        balance: f64,      // Private: Only this 'bank' module can see it
    }

    impl BankAccount {
        pub fn new(owner: &str, balance: f64) -> Self {
            BankAccount {
                owner: owner.to_string(),
                balance,
            }
        }

        pub fn get_balance(&self) -> f64 {
            self.balance
        }
    }
}

fn main() {
    let account = bank::BankAccount::new("Alice", 1000.0);
    
    // Allowed: 'owner' is pub
    println!("{}", account.owner);

    // ERROR: 'balance' is private!
    // println!("{}", account.balance); 
}

```

**Why Use Encapsulation?**

* It ensures you cannot accidentally set `balance = -500.0`. You *must* go through a method that validates the input.

---

## **Encapsulation Using Getters and Setters**

Since Rust fields are often private, we access them using methods.

**Rust Idiom:**

* **Getter:** naming convention is `field_name()`, not `get_field_name()`.
* **Setter:** naming convention is `set_field_name()`.

### **Example: Getters and Setters in Rust**

```rust
pub struct Employee {
    name: String,
    age: u8,
}

impl Employee {
    // Setter
    pub fn set_age(&mut self, age: u8) {
        if age > 18 {
            self.age = age;
        } else {
            println!("Age must be greater than 18");
        }
    }

    // Getter (Note: no 'get_' prefix)
    pub fn age(&self) -> u8 {
        self.age
    }
}

```

---

## **Encapsulation and Data Hiding**

We hide implementation details so the user doesn't need to worry about complex validation logic.

### **Example: Hiding Implementation Details**

```rust
mod finance {
    pub struct Account {
        balance: f64,
    }

    impl Account {
        pub fn new(balance: f64) -> Self {
            Account { balance }
        }

        // Private helper method (Not 'pub', so invisible outside)
        fn validate(&self, amount: f64) -> bool {
            amount > 0.0 && amount <= self.balance
        }

        // Public API
        pub fn withdraw(&mut self, amount: f64) {
            if self.validate(amount) {
                self.balance -= amount;
                println!("Withdrawal Successful: {}", amount);
            } else {
                println!("Invalid transaction");
            }
        }
    }
}

```

**Why Hide Data?**

* **Safety:** The `validate` logic cannot be bypassed by external code.
* **Simplicity:** The user just calls `withdraw`; they don't need to know *how* validation works.

---

## **Real-World Example: Payment System**

A common real-world use case is processing payments where sensitive data (like card numbers) should never be exposed directly.

```rust
mod payment_system {
    pub struct CreditCard {
        number: String, // Private!
        amount: f64,
    }

    impl CreditCard {
        pub fn new(number: &str, amount: f64) -> Self {
            CreditCard {
                number: CreditCard::mask(number), // Internal logic
                amount,
            }
        }

        // Private utility function
        fn mask(real_number: &str) -> String {
            let last_4 = &real_number[real_number.len()-4..];
            format!("****-****-****-{}", last_4)
        }

        pub fn process(&self) {
            println!("Charging {} to card {}", self.amount, self.number);
        }
    }
}

```

---

## 📚 New Terminology (Java vs. Rust)

| Term | Java Equivalent | Detailed Explanation |
| --- | --- | --- |
| **Module (`mod`)** | Package / Class | In Rust, the boundary for privacy is the **Module**, not the Class. Private items in a struct are visible to everything in the same `mod`. |
| **`pub`** | `public` | Makes an item visible to other modules. |
| **(No modifier)** | `private` / package-private | By default, everything in Rust is private. It is only visible within the current module and its children. |
| **`pub(crate)`** | N/A | Visible to the entire project (crate), but hidden from anyone who uses your project as a library. |
| **`&mut self`** | `this` (implicitly mutable) | In Java, you can always modify `this`. In Rust, you must explicitly say `&mut self` if a method changes data (like a Setter). |
| **Getter convention** | `getName()` | In Rust, we simply use the field name: `name()`. |

---

## File: oop/rust/inheritance/README.md

# Inheritance in Rust (Traits & Composition)

## Introduction

**Inheritance** is one of the core principles of Object-Oriented Programming (OOP). It allows a class (subclass or child class) to acquire the properties and behaviors of another class (superclass or parent class). This promotes **code reuse**, **scalability**, and **maintainability**.

**Does Rust support Inheritance?**
No, Rust does **not** support classical inheritance (e.g., `class Dog extends Animal`). Rust takes a different approach called **Composition over Inheritance**.

Instead of inheriting fields and methods from a parent class, Rust uses:
1.  **Traits:** To share behavior (methods).
2.  **Composition:** To share state (data/fields).

## **What is Inheritance?**

In traditional OOP (Java), **Inheritance** is a mechanism where a child class derives properties and behaviors from a parent class.

In Rust, since we cannot use `extends`, we achieve the same functionality by:
- **Implementing Traits:** A struct implements a specific trait to gain its behavior.
- **Embedding Structs:** A struct contains another struct as a field to reuse its data.

### **Key Benefits of the Rust Approach**

- **Avoids the "Diamond Problem":** Multiple inheritance of state is impossible, preventing complex conflicts.
- **Explicit Dependencies:** You clearly see what data a struct depends on (it's listed in the fields).
- **Flexible Behavior:** You can implement many traits for a single struct, offering more flexibility than single inheritance.

---

## **How to Implement "Inheritance" in Rust**

Since Rust does not have `extends`, we use **Traits** for behavior and **Composition** for data.

### **Step 1: Create a Parent Behavior (Trait)**

The parent trait contains common method signatures and default implementations.

```rust
// Parent Trait (Behavior)
pub trait Animal {
    fn name(&self) -> &String; // Abstract method (getter)

    // Default implementation (Shared Behavior)
    fn eat(&self) {
        println!("{} is eating...", self.name());
    }
}

```

### **Step 2: Create a Child Struct using `impl`**

The child struct implements the properties and methods of the parent trait.

```rust
// Child Struct (Data)
pub struct Dog {
    pub name: String,
    pub breed: String,
}

// Implementing the Trait (The "Inheritance" link)
impl Animal for Dog {
    fn name(&self) -> &String {
        &self.name
    }
    
    // 'eat()' is inherited automatically from the Trait
}

impl Dog {
    // Dog-specific method
    fn bark(&self) {
        println!("{} is barking...", self.name);
    }
}

```

### **Step 3: Use the Child Struct**

Now, let's create an object and use the inherited methods.

```rust
fn main() {
    let my_dog = Dog { 
        name: "Buddy".to_string(),
        breed: "Golden Retriever".to_string(),
    };
    
    // Inherited from Animal trait
    my_dog.eat(); 
    
    // Defined in Dog impl block
    my_dog.bark(); 
}

```

### **Output:**

```
Buddy is eating...
Buddy is barking...

```

---

## **Types of "Inheritance" Patterns in Rust**

Although Rust lacks class inheritance, we can replicate standard OOP patterns.

### **1. Single Inheritance (Trait Implementation)**

A struct implements a single trait.

```rust
trait Parent {
    fn show(&self) {
        println!("This is the parent behavior");
    }
}

struct Child;

impl Parent for Child {} // Inherits 'show'

```

### **2. Multilevel Inheritance (Supertraits)**

A trait inherits from another trait. This is called a **Supertrait**.

```rust
trait Grandparent {
    fn show_grand(&self);
}

// Parent requires Grandparent to be implemented first
trait Parent: Grandparent {
    fn show_parent(&self);
}

struct Child;

// You must implement both
impl Grandparent for Child { 
    fn show_grand(&self) { println!("Grandparent"); } 
}
impl Parent for Child { 
    fn show_parent(&self) { println!("Parent"); } 
}

```

### **3. Hierarchical Inheritance**

A single parent trait is implemented by multiple different structs.

```rust
trait Entity {
    fn id(&self) -> u32;
}

struct User { id: u32 }
impl Entity for User { fn id(&self) -> u32 { self.id } }

struct Product { id: u32 }
impl Entity for Product { fn id(&self) -> u32 { self.id } }

```

---

## **Method Overriding in Rust**

Method overriding allows a struct to **redefine** a default method provided by a Trait.

```rust
trait Animal {
    fn make_sound(&self) {
        println!("Generic Animal Sound");
    }
}

struct Dog;

impl Animal for Dog {
    // Overriding the default method
    fn make_sound(&self) {
        println!("Dog barks! 🐶");
    }
}

```

### **Usage**

```rust
fn main() {
    let my_animal = Dog;
    my_animal.make_sound(); // Runs overridden version
}

```

### **Output:**

```
Dog barks! 🐶

```

---

## **The `super` Concept in Rust (Accessing Parent)**

In Java, `super` calls the parent class. In Rust, we use **Composition** to access "parent" data explicitly.

1. **Composition:** Embedding one struct inside another.
2. **Delegation:** Calling the inner struct's methods.

```rust
// The "Parent" Data
struct Organism {
    age: u8,
}

impl Organism {
    fn breathe(&self) { println!("Breathing..."); }
}

// The "Child" Struct
struct Dog {
    organism: Organism, // Composition (Has-a)
}

impl Dog {
    fn breathe(&self) {
        // Explicitly calling the "Parent" (inner struct)
        self.organism.breathe(); 
        println!("...and panting!");
    }
}

```

### **Summary Table**

| Concept | Java (Inheritance) | Rust (Idiomatic) |
| --- | --- | --- |
| **Relationship** | `Dog extends Animal` | `Dog implements Animal` (Trait) |
| **Data Sharing** | Inherited automatically | Composition (`dog.animal.field`) |
| **Method Sharing** | Inherited from Parent Class | Default Trait Methods |
| **Overriding** | `@Override` | `impl Trait` block |
| **Philosophy** | **Is-a** relationship | **Has-a** & **Can-do** relationship |