> ## Documentation Index
> Fetch the complete documentation index at: https://resources.devweekends.com/llms.txt
> Use this file to discover all available pages before exploring further.
# SOLID Introduction
> Five magic rules that make your code super clean and easy to change!
**Time to Master**: \~30 minutes | **Difficulty**: Beginner-friendly | **Prerequisite**: Basic OOP understanding
## ๐๏ธ What are SOLID Principles?
Imagine building with LEGO blocks:
* **Good LEGO sets**: Pieces fit together nicely, easy to change, fun to build
* **Bad LEGO sets**: Pieces stuck together with glue, can't change anything without breaking
SOLID principles are **five rules** that help you write code like good LEGO sets - modular, flexible, and maintainable!
Single Responsibility
Open/Closed
Liskov Substitution
Interface Segregation
Dependency Inversion
***
## ๐ฏ Why Learn SOLID?
Modify one thing without breaking everything else
Simpler classes = fewer places for bugs to hide
Small, focused classes are easy to test
Others can understand and work with your code
**Interview Alert**: SOLID principles are asked in almost every LLD interview! "Does your design follow SOLID?" is a common follow-up question.
**Think of SOLID like building codes for construction.** A building inspector does not care whether your house is Victorian or modern -- they care that the foundation is sound, the wiring is safe, and the plumbing does not cross-contaminate. SOLID principles are the building codes of software design. They do not prescribe a specific architecture, but they ensure that whatever you build can be maintained, extended, and debugged by the next person who opens the codebase.
***
## ๐ The Five Principles at a Glance
### S - Single Responsibility Principle (SRP)
> **"Do ONE thing, and do it well!"**
Like how a chef COOKS, a waiter SERVES, and a cashier handles PAYMENT - each has one job.
```python theme={null}
# โ BAD: UserManager does EVERYTHING
class UserManager:
def create_user(self): pass
def send_email(self): pass # Email is a different job!
def generate_report(self): pass # Reporting is different too!
# โ
GOOD: Each class has ONE job
class UserService:
def create_user(self): pass
class EmailService:
def send_email(self): pass
class ReportService:
def generate_report(self): pass
```
***
### O - Open/Closed Principle (OCP)
> **"Open for extension, closed for modification!"**
Like adding new apps to your phone without rewriting the operating system.
```python theme={null}
# โ BAD: Must modify when adding new shapes
class AreaCalculator:
def calculate(self, shape):
if shape.type == "circle":
return 3.14 * shape.radius ** 2
elif shape.type == "rectangle": # Must keep adding elif!
return shape.width * shape.height
# โ
GOOD: Add new shapes without changing existing code
class Shape:
def area(self): pass
class Circle(Shape):
def area(self):
return 3.14 * self.radius ** 2
class Rectangle(Shape):
def area(self):
return self.width * self.height
# Adding Triangle? Just create new class, don't touch existing!
```
***
### L - Liskov Substitution Principle (LSP)
> **"Children should be able to replace their parents!"**
If you expect an Animal, a Dog should work perfectly - without surprises.
```python theme={null}
# โ BAD: Penguin breaks the Bird contract
class Bird:
def fly(self): pass
class Penguin(Bird): # But penguins can't fly! ๐ง
def fly(self):
raise Exception("I can't fly!") # Surprise!
# โ
GOOD: Separate flying and non-flying birds
class Bird:
def eat(self): pass
class FlyingBird(Bird):
def fly(self): pass
class Penguin(Bird): # No fly() method to break
def swim(self): pass
```
***
### I - Interface Segregation Principle (ISP)
> **"Don't force me to implement things I don't need!"**
Like a printer that only prints - it shouldn't need a fax feature if you don't use fax.
```python theme={null}
# โ BAD: Forces all workers to implement every method
class Worker:
def work(self): pass
def eat(self): pass
def sleep(self): pass
class Robot(Worker): # Robots don't eat or sleep!
def eat(self): raise Exception("I don't eat!")
def sleep(self): raise Exception("I don't sleep!")
# โ
GOOD: Separate interfaces
class Workable:
def work(self): pass
class Eatable:
def eat(self): pass
class Robot(Workable): # Only implements what it needs
def work(self): pass
```
***
### D - Dependency Inversion Principle (DIP)
> **"Depend on abstractions, not concrete things!"**
Like a phone charger - you plug into the WALL SOCKET (abstraction), not directly into power lines!
```python theme={null}
# โ BAD: High-level depends on low-level details
class PaymentProcessor:
def __init__(self):
self.stripe = StripeAPI() # Directly tied to Stripe!
def pay(self, amount):
self.stripe.charge(amount) # What if we switch to PayPal?
# โ
GOOD: Depend on abstraction
class PaymentGateway: # Abstract
def charge(self, amount): pass
class PaymentProcessor:
def __init__(self, gateway: PaymentGateway): # Accept ANY gateway
self.gateway = gateway
def pay(self, amount):
self.gateway.charge(amount) # Works with Stripe, PayPal, anything!
```
***
## ๐ฎ Interactive Memory Aid
Remember SOLID with this story:
The chef only COOKS - doesn't clean, serve, or manage money
Add new dishes to the menu WITHOUT rewriting the kitchen
If menu says "pasta", any pasta type should work the same
Waiter takes orders - doesn't need to know cooking
Kitchen depends on RECIPE standards, not specific ingredients
***
## ๐งช Quick Self-Test
**Q1: Which principle does this violate?**
```python theme={null}
class Report:
def generate_data(self): pass
def format_as_pdf(self): pass
def send_email(self): pass
```
Answer
**Single Responsibility Principle (S)** - The Report class is doing THREE things: generating data, formatting, and sending email!
***
**Q2: Which principle does this violate?**
```python theme={null}
class Calculator:
def calculate(self, operation, a, b):
if operation == "add": return a + b
elif operation == "subtract": return a - b
# Must modify here for each new operation!
```
Answer
**Open/Closed Principle (O)** - You have to MODIFY the class every time you add a new operation. Use polymorphism instead!
***
**Q3: Which principle does this violate?**
```python theme={null}
class Machine:
def print_doc(self): pass
def scan_doc(self): pass
def fax_doc(self): pass
def copy_doc(self): pass
class SimplePrinter(Machine): # Only prints!
def scan_doc(self): raise NotImplementedError
def fax_doc(self): raise NotImplementedError
def copy_doc(self): raise NotImplementedError
```
Answer
**Interface Segregation Principle (I)** - SimplePrinter is forced to implement methods it doesn't need. Split into smaller interfaces!
***
## ๐ The SOLID Journey
Now let's dive deep into each principle with fun examples and exercises!
One class, one job - like workers in a factory
Add features without changing code - like plugins
Children behave like parents - no surprises
Many specific interfaces - not one giant one
Depend on contracts - not implementations
***
## Interview Insight
**How SOLID shows up in interviews:** Interviewers rarely ask "explain the Liskov Substitution Principle" in isolation. Instead, they give you a design problem and watch whether your design *naturally follows* SOLID. For example, when you separate UserRepository from EmailService (SRP), use a PaymentGateway interface instead of if/elif chains (OCP), ensure all subclasses honor parent contracts (LSP), define small focused interfaces (ISP), and inject dependencies rather than hardcoding them (DIP) -- you are demonstrating SOLID without naming it. The highest-signal move is to name the principle when you make a design choice: "I am splitting this into two classes because I want each to have a single reason to change -- that is the Single Responsibility Principle." This shows you are not just designing intuitively but reasoning deliberately.
***
## ๐ Start Your Journey!
Learn the first and most important SOLID principle - keeping your classes focused!