OOP Fundamentals — Design Review

Easy
FundamentalsSOLIDOOP

OOP Fundamentals for LLD Interviews

Before tackling design problems, master these foundational concepts:

The 4 Pillars of OOP

1. Encapsulation Hide internal state. Only expose what's necessary through a public interface.

class BankAccount {
    private double balance; // private — hidden
    public void deposit(double amount) { // controlled access
        if (amount > 0) balance += amount;
    }
}

2. Abstraction Hide complexity behind simple interfaces.

interface Shape {
    double area(); // I don't care HOW, just that it works
}

3. Inheritance IS-A relationship. Reuse and extend.

class Car extends Vehicle { ... } // Car IS-A Vehicle

4. Polymorphism Same interface, different behavior.

Shape s = new Circle(5);
s.area(); // calls Circle.area(), not Rectangle.area()

SOLID Principles

| Principle | Meaning | Violation Example | |-----------|---------|-------------------| | S — Single Responsibility | One class, one reason to change | UserManager handles auth, DB, and email | | O — Open/Closed | Open for extension, closed for modification | Adding a new payment method requires editing existing class | | L — Liskov Substitution | Subclass must be usable in place of parent | Square extends Rectangle breaks width/height independence | | I — Interface Segregation | Don't force clients to implement unused methods | Animal interface has fly() but Fish implements it | | D — Dependency Inversion | Depend on abstractions, not concretions | OrderService directly instantiates MySQLDatabase |


Common Design Patterns in LLD Interviews

| Pattern | Type | Use When | |---------|------|----------| | Singleton | Creational | Only one instance needed (ParkingLot, ATM) | | Factory | Creational | Create objects without specifying exact class | | Observer | Behavioral | One-to-many event notifications | | Strategy | Behavioral | Swap algorithms at runtime | | State | Behavioral | Object behavior changes with internal state | | Composite | Structural | Tree structures (File System) | | Decorator | Structural | Add behavior without modifying class |


Practice Exercise

Implement the following to test your understanding:

!Constraints

- Implement a Shape hierarchy with Circle, Rectangle, Triangle - Each shape must implement area() and perimeter() - Create a ShapeFactory that creates shapes by type string - Demonstrate polymorphism by storing different shapes in a List<Shape> - Ensure all shapes follow the Liskov Substitution Principle
Output

Run your code to see output here.