SOLID Principles Made Simple: A Developer’s Guide with Real-World Java Examples

Writing clean, maintainable code is like building a house — you need solid foundations. The SOLID principles, introduced by Robert C. Martin (Uncle Bob), pro...

Posted Jun 7, 2026

By Nikhil Tiwari

8 min read

SOLID Principles Made Simple: A Developer’s Guide with Real-World Java Examples

Writing clean, maintainable code is like building a house — you need solid foundations. The SOLID principles, introduced by Robert C. Martin (Uncle Bob), provide exactly that foundation. These five principles might sound intimidating at first, but they’re actually common-sense guidelines that will make your code easier to understand, modify, and extend.

Let’s break down each principle with real-world examples that you can relate to and implement immediately.

1. Single Responsibility Principle (SRP)

“A class should have only one reason to change.”

Think of this like a Swiss Army knife versus specialized tools. While a Swiss Army knife can do many things, a professional carpenter uses dedicated tools because each tool excels at its specific job.

❌ Violating SRP

        
      
// This class has too many responsibilities
public class User {
  private String name;
  private String email;
  // Responsibility 1: User data management
  public void setName(String name) {
    this.name = name;
  }
  public String getName() {
    return name;
  }
  // Responsibility 2: Email validation
  public boolean isValidEmail(String email) {
    return email.contains("@") && email.contains(".");
  }
  // Responsibility 3: Database operations
  public void saveToDatabase() {
    // Database saving logic
    System.out.println("Saving user to database...");
  }
  // Responsibility 4: Email sending
  public void sendWelcomeEmail() {
    // Email sending logic
    System.out.println("Sending welcome email...");
  }
}

✅ Following SRP

        
      
public class User {
  private String name;
  private String email;
  public User(String name, String email) {
    this.name = name;
    this.email = email;
  }
  public String getName() {
    return name;
  }
  public String getEmail() {
    return email;
  }
}

        
      
public class EmailValidator {
  public boolean isValid(String email) {
    return email != null && email.contains("@") && email.contains(".");
  }
}

        
      
public class UserRepository {
  public void save(User user) {
    System.out.println("Saving " + user.getName() + " to database...");
  }
}

        
      
public class EmailService {
  public void sendWelcomeEmail(User user) {
    System.out.println("Sending welcome email to " + user.getEmail());
  }
}

Why this matters:Now if you need to change how emails are validated, you only touch theEmailValidatorclass. Database logic changes? Only theUserRepositoryis affected.

2. Open/Closed Principle (OCP)

“Software entities should be open for extension but closed for modification.”

Imagine you’re designing a pizza restaurant. Instead of rebuilding your entire kitchen every time you add a new pizza type, you create a system where new pizzas can be added without changing the existing cooking process.

❌ Violating OCP

        
      
public class PizzaPriceCalculator {
  public double calculatePrice(String pizzaType) {
    switch (pizzaType) {
      case "Margherita":
        return 12.99;
      case "Pepperoni":
        return 15.99;
      case "Hawaiian":
        return 17.99;
      default:
        return 0;
    }
    // Every new pizza type requires modifying this method!
  }
}

✅ Following OCP

        
      
// Abstract base class
public abstract class Pizza {
  protected String name;
  public Pizza(String name) {
    this.name = name;
  }
  public abstract double getPrice();
  public String getName() {
    return name;
  }
}

        
      
// Concrete implementations
public class MargheritaPizza extends Pizza {
  public MargheritaPizza() {
    super("Margherita");
  }
  @Override
  public double getPrice() {
    return 12.99;
  }
}

        
      
public class PepperoniPizza extends Pizza {
  public PepperoniPizza() {
    super("Pepperoni");
  }
  @Override
  public double getPrice() {
    return 15.99;
  }
}

        
      
// Calculator that works with any pizza type
public class PizzaPriceCalculator {
  public double calculatePrice(Pizza pizza) {
    return pizza.getPrice(); // No modification needed for new pizza types!
  }
}

        
      
// Adding new pizza types without modifying existing code
public class VeggiePizza extends Pizza {
  public VeggiePizza() {
    super("Veggie Supreme");
  }
  @Override
  public double getPrice() {
    return 16.99;
  }
}

Why this matters:You can add new pizza types without touching the calculator. Your existing code remains stable while new features can be added seamlessly.

3. Liskov Substitution Principle (LSP)

“Objects of a superclass should be replaceable with objects of its subclasses without breaking the application.”

Think of this like substitute teachers. A substitute should be able to perform the same basic teaching functions as the regular teacher, even if their style is different.

❌ Violating LSP

        
      
public class Bird {
  public void fly() {
    System.out.println("Flying...");
  }
}

        
      
public class Penguin extends Bird {
  @Override
  public void fly() {
    throw new UnsupportedOperationException("Penguins can't fly!");
    // This breaks the expected behavior of Bird
  }
}

        
      
// This will crash when a Penguin is used
public class BirdWatcher {
  public void watchBird(Bird bird) {
    bird.fly(); // Crashes if bird is a Penguin!
  }
}

✅ Following LSP

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

        
      
public class FlyingBird extends Bird {
  @Override
  public void move() {
    System.out.println("Flying through the sky...");
  }
}

        
      
public class SwimmingBird extends Bird {
  @Override
  public void move() {
    System.out.println("Swimming in water...");
  }
}

        
      
public class Eagle extends FlyingBird {
  // Inherits flying behavior - works perfectly as a FlyingBird
}

        
      
public class Penguin extends SwimmingBird {
  // Inherits swimming behavior - works perfectly as a SwimmingBird
}

        
      
public class BirdWatcher {
  public void watchBird(Bird bird) {
    bird.move(); // Works with any Bird subclass
  }
}

Why this matters:Any Bird subclass can be used interchangeably without breaking your application. The contract is honored by all implementations.

4. Interface Segregation Principle (ISP)

“No client should be forced to depend on methods it does not use.”

This is like having different remote controls for different devices. Your TV remote doesn’t need air conditioning buttons, and your AC remote doesn’t need volume controls.

❌ Violating ISP

        
      
// Fat interface that forces unnecessary dependencies
public interface WorkerInterface {
  void work();
  void eat();
  void sleep();
}

        
      
public class HumanWorker implements WorkerInterface {
  @Override
  public void work() {
    System.out.println("Human working...");
  }
  @Override
  public void eat() {
    System.out.println("Human eating...");
  }
  @Override
  public void sleep() {
    System.out.println("Human sleeping...");
  }
}

        
      
public class RobotWorker implements WorkerInterface {
  @Override
  public void work() {
    System.out.println("Robot working...");
  }
  @Override
  public void eat() {
    // Robots don't eat! But forced to implement
    throw new UnsupportedOperationException("Robots don't eat");
  }
  @Override
  public void sleep() {
    // Robots don't sleep! But forced to implement
    throw new UnsupportedOperationException("Robots don't sleep");
  }
}

✅ Following ISP

        
      
// Segregated interfaces
public interface Workable {
  void work();
}

        
      
public interface Eatable {
  void eat();
}

        
      
public interface Sleepable {
  void sleep();
}

        
      
// Humans implement all relevant interfaces
public class HumanWorker implements Workable, Eatable, Sleepable {
  @Override
  public void work() {
    System.out.println("Human working...");
  }
  @Override
  public void eat() {
    System.out.println("Human eating...");
  }
  @Override
  public void sleep() {
    System.out.println("Human sleeping...");
  }
}

        
      
// Robots only implement what they can do
public class RobotWorker implements Workable {
  @Override
  public void work() {
    System.out.println("Robot working efficiently...");
  }
}

        
      
// Usage
public class WorkManager {
  public void manageWork(Workable worker) {
    worker.work(); // Works with both humans and robots
  }
}

Why this matters:Classes only depend on the methods they actually need. This reduces coupling and makes your code more flexible.

5. Dependency Inversion Principle (DIP)

“Depend on abstractions, not concretions.”

Think of this like electrical outlets. Your devices don’t care about the specific power plant generating electricity — they just need the standard interface (the outlet). This allows you to plug in anywhere without worrying about the underlying implementation.

❌ Violating DIP

        
      
// High-level class depending on low-level concrete class
public class EmailService {
  private GmailSender gmailSender; // Tightly coupled to Gmail
  public EmailService() {
    this.gmailSender = new GmailSender(); // Hard dependency
  }
  public void sendEmail(String message) {
    gmailSender.send(message);
    // What if we want to use Outlook or another service?
  }
}

        
      
public class GmailSender {
  public void send(String message) {
    System.out.println("Sending via Gmail: " + message);
  }
}

✅ Following DIP

        
      
// Abstract interface
public interface EmailSender {
  void send(String message);
}

        
      
// Concrete implementations
public class GmailSender implements EmailSender {
  @Override
  public void send(String message) {
    System.out.println("Sending via Gmail: " + message);
  }
}

        
      
public class OutlookSender implements EmailSender {
  @Override
  public void send(String message) {
    System.out.println("Sending via Outlook: " + message);
  }
}

        
      
// High-level class depends on abstraction
public class EmailService {
  private EmailSender emailSender;
  public EmailService(EmailSender emailSender) {
    this.emailSender = emailSender; // Dependency injection
  }
  public void sendEmail(String message) {
    emailSender.send(message); // Works with any EmailSender implementation
  }
}

        
      
// Usage
public class Application {
  public static void main(String[] args) {
    // Easy to switch between different email providers
    EmailService gmailService = new EmailService(new GmailSender());
    EmailService outlookService = new EmailService(new OutlookSender());
    gmailService.sendEmail("Hello via Gmail!");
    outlookService.sendEmail("Hello via Outlook!");
  }
}

Why this matters:You can easily switch between different email providers without changing the EmailService class. Testing becomes easier because you can inject mock implementations.

Putting It All Together

The SOLID principles work together to create maintainable, flexible code:

SRPkeeps your classes focused and easy to understand
OCPallows you to add new features without breaking existing code
LSPensures your inheritance hierarchies work correctly
ISPprevents unnecessary dependencies between components
DIPmakes your code flexible and testable

Quick Checklist for Clean Code

Before you commit your code, ask yourself:

Single Responsibility: Does this class have only one reason to change?
Open/Closed: Can I add new functionality without modifying existing code?
Liskov Substitution: Can I replace any parent class with its child classes?
Interface Segregation: Are my interfaces focused and not bloated?
Dependency Inversion: Am I depending on abstractions rather than concrete implementations?

Remember, these principles are guidelines, not rigid rules. The goal is to write code that’s easy to read, maintain, and extend. Start by applying one principle at a time, and gradually incorporate them all into your development workflow.

Your future self (and your teammates) will thank you for writing SOLID code!

programming, SOLID

java

This post is licensed under CC BY 4.0 by the author.

SOLID Principles Made Simple: A Developer’s Guide with Real-World Java Examples

1. Single Responsibility Principle (SRP)

❌ Violating SRP

✅ Following SRP

2. Open/Closed Principle (OCP)

❌ Violating OCP

✅ Following OCP

3. Liskov Substitution Principle (LSP)

❌ Violating LSP

✅ Following LSP

4. Interface Segregation Principle (ISP)

❌ Violating ISP

✅ Following ISP

5. Dependency Inversion Principle (DIP)

❌ Violating DIP

✅ Following DIP

Putting It All Together

Quick Checklist for Clean Code

Trending Tags