SOLID Principles Cheat Sheet 🚀

Quick Memory Aid: "SOLID"

S - Single Responsibility Principle
O - Open/Closed Principle
L - Liskov Substitution Principle
I - Interface Segregation Principle
D - Dependency Inversion Principle

1. Single Responsibility Principle (SRP) 📝

"One Class, One Job"

Official Definition: A class should have only one reason to change, meaning that a class should have only one job or responsibility.

Rule: A class should have only one reason to change.

❌ Bad Example:

public class Employee{
    public void SaveEmployee() { /* Save to database */ }
    public void SendEmail() { /* Send email notification */ }
    public void GenerateReport() { /* Generate PDF report */ }
}// Problem: 3 different reasons to change this class!

✅ Good Example:

public class Employee{
    public string Name { get; set; }
    public decimal Salary { get; set; }
}

public class EmployeeRepository{
    public void SaveEmployee(Employee emp) { /* Save logic */ }
}

public class EmailService{
    public void SendEmail(string message) { /* Email logic */ }
}

public class ReportGenerator{
    public void GenerateReport(Employee emp) { /* Report logic */ }
}

Memory Tip: "Single = Solo = One job per class"

2. Open/Closed Principle (OCP) 🔓🔒

"Open for Extension, Closed for Modification"

Official Definition: Software entities (classes, modules, functions, etc.) should be open for extension but closed for modification. This means you should be able to add new functionality without changing existing code.

Rule: Classes should be open for extension but closed for modification.

❌ Bad Example:

public class AreaCalculator{
    public double CalculateArea(object shape)
    {
        if (shape is Rectangle rect)
            return rect.Width * rect.Height;
        else if (shape is Circle circle)
            return Math.PI * circle.Radius * circle.Radius;
        // Need to modify this method for new shapes!
        return 0;
    }
}

✅ Good Example:

public abstract class Shape{
    public abstract double CalculateArea();
}

public class Rectangle : Shape{
    public double Width { get; set; }
    public double Height { get; set; }
    
    public override double CalculateArea() => Width * Height;
}

public class Circle : Shape{
    public double Radius { get; set; }
    
    public override double CalculateArea() => Math.PI * Radius * Radius;
}

public class AreaCalculator{
    public double CalculateArea(Shape shape) => shape.CalculateArea();
    // No need to modify for new shapes!
}

Memory Tip: "Open door for new features, Closed door for changes"

3. Liskov Substitution Principle (LSP) 🔄

"Subclasses Must Be Substitutable"

Official Definition: Objects of a superclass should be replaceable with objects of its subclasses without breaking the application. In other words, if S is a subtype of T, then objects of type T may be replaced with objects of type S without altering any of the desirable properties of the program.

Rule: Objects of a superclass should be replaceable with objects of a subclass without breaking functionality.

❌ Bad Example:

public class Bird{
    public virtual void Fly() => Console.WriteLine("Flying...");}

public class Penguin : Bird{
    public override void Fly() => throw new Exception("Can't fly!");
    // Breaks LSP - penguin can't substitute bird behavior}

✅ Good Example:

public abstract class Bird{
    public abstract void Move();}

public class FlyingBird : Bird{
    public override void Move() => Console.WriteLine("Flying...");}

public class SwimmingBird : Bird{
    public override void Move() => Console.WriteLine("Swimming...");}

public class Eagle : FlyingBird { }public class Penguin : SwimmingBird { }

Memory Tip: "Lisa (Liskov) can substitute any family member in photos"

4. Interface Segregation Principle (ISP) ✂️

"Many Small Interfaces > One Big Interface"

Official Definition: No client should be forced to depend on methods it does not use. This principle suggests that it's better to have many specific interfaces rather than one general-purpose interface.

Rule: Clients should not be forced to depend on interfaces they don't use.

❌ Bad Example:

public interface IWorker{
    void Work();
    void Eat();
    void Sleep();}

public class Robot : IWorker{
    public void Work() => Console.WriteLine("Working...");
    public void Eat() => throw new NotImplementedException(); // Robot doesn't eat!
    public void Sleep() => throw new NotImplementedException(); // Robot doesn't sleep!}

✅ Good Example:

public interface IWorkable{
    void Work();}

public interface IFeedable{
    void Eat();}

public interface ISleepable{
    void Sleep();}

public class Human : IWorkable, IFeedable, ISleepable{
    public void Work() => Console.WriteLine("Working...");
    public void Eat() => Console.WriteLine("Eating...");
    public void Sleep() => Console.WriteLine("Sleeping...");}

public class Robot : IWorkable{
    public void Work() => Console.WriteLine("Working...");
    // Only implements what it needs!}

Memory Tip: "Interface Separation = Split interfaces like pizza slices"

5. Dependency Inversion Principle (DIP) 🔃

"Depend on Abstractions, Not Concretions"

Official Definition: High-level modules should not depend on low-level modules. Both should depend on abstractions. Abstractions should not depend on details. Details should depend on abstractions.

Rule: High-level modules should not depend on low-level modules. Both should depend on abstractions.

❌ Bad Example:

public class EmailService{
    public void SendEmail(string message) { /* Send email */ }}

public class NotificationService{
    private EmailService emailService = new EmailService(); // Tight coupling!
    
    public void SendNotification(string message)
    {
        emailService.SendEmail(message);
    }}

✅ Good Example:

public interface IMessageService{
    void SendMessage(string message);}

public class EmailService : IMessageService{
    public void SendMessage(string message) => Console.WriteLine($"Email: {message}");}

public class SMSService : IMessageService{
    public void SendMessage(string message) => Console.WriteLine($"SMS: {message}");}

public class NotificationService{
    private readonly IMessageService messageService;
    
    public NotificationService(IMessageService messageService)
    {
        this.messageService = messageService; // Dependency injection!
    }
    
    public void SendNotification(string message)
    {
        messageService.SendMessage(message);
    }}

Memory Tip: "Depend on Interface (abstract), not Implementation (concrete)"

🎯 Quick Reference Summary

Principle	Simple Rule	Memory Hook
SRP	One class, one job	Single = Solo
OCP	Extend, don't modify	Open door, closed door
LSP	Child can replace parent	Lisa substitutes family
ISP	Small focused interfaces	Split like pizza slices
DIP	Depend on abstractions	Interface over Implementation

🏆 Benefits of Following SOLID:

✅ Maintainable code
✅ Testable components
✅ Flexible architecture
✅ Reusable modules
✅ Scalable applications