Design Patterns and the SOLID Principles

What Are Design Patterns?

Design patterns are reusable solutions to common problems in software design. They are not finished code you copy and paste. They are templates describing how to structure classes and objects to solve a specific kind of problem in a way that is proven, flexible, and easy to maintain.

Patterns emerged from observing thousands of real-world projects. When developers kept solving the same problem the same way, that recurring solution became a pattern. Learning patterns gives you a shared vocabulary with other developers and a toolbox of proven approaches.

The SOLID Principles

Before diving into individual patterns, you need to understand SOLID - five principles that underpin good object-oriented design. Most design patterns exist to help you follow one or more of these principles.

+-----------------+
|   Client code   |
+-----------------+
        |
        | use (DIP)
        |
        >
+---------------------+
| NotificationSender  |
|     (abstraction)   |
+---------------------+
            ^      ^
            |      |
    +-------+--+   +---+-------+
    |  Email    |   |  SMS     |
    |  Sender   |   |  Sender  |
    +-----------+   +----------+

Single Responsibility Principle (SRP)

A class should have only one reason to change. This means one class = one job. If you find a class handling both database access and email sending, split it into two classes.

public class User {
    private String name;
    private String email;

    public String getName() { return name; }
    public String getEmail() { return email; }
}

public class UserRepository {
    public void save(User user) {
        // persist to database
    }
}

public class EmailService {
    public void sendWelcome(User user) {
        // send email
    }
}

Each class has one job: User holds data, UserRepository handles persistence, EmailService handles emails. Changing the email format does not force changes to the persistence code.

Open/Closed Principle (OCP)

Software entities should be open for extension but closed for modification. You can add new behavior without changing existing code.

public interface PaymentProcessor {
    void process(double amount);
}

public class CreditCardProcessor implements PaymentProcessor {
    public void process(double amount) {
        // charge credit card
    }
}

public class PayPalProcessor implements PaymentProcessor {
    public void process(double amount) {
        // process via PayPal
    }
}

To add a new payment method you create a new class - you never touch existing code.

Liskov Substitution Principle (LSP)

Objects of a superclass should be replaceable with objects of its subclasses without breaking the program. If Square extends Rectangle, setting width and height on a Square must not produce unexpected behavior.

Interface Segregation Principle (ISP)

Do not force a class to implement interfaces it does not use. Instead of one fat interface, create several small, specific ones.

Dependency Inversion Principle (DIP)

High-level modules should not depend on low-level modules. Both should depend on abstractions. A class should depend on an interface, not a concrete implementation.

public class NotificationService {
    private final NotificationSender sender;

    public NotificationService(NotificationSender sender) {
        this.sender = sender;
    }

    public void notify(String message) {
        sender.send(message);
    }
}

NotificationService depends on the abstraction (NotificationSender), not a concrete class - this is DIP in action. Swapping EmailSender for SMSSender needs no changes to NotificationService, which also honors OCP.

SRP keeps classes small, OCP keeps them extensible, LSP guarantees safe substitution, ISP keeps interfaces lean, and DIP inverts control towards abstractions. Every design pattern you learn will ultimately be an implementation of one or more of these ideas.

Key Points

• Design patterns are reusable templates for solving common design problems.
• SOLID principles are the foundation - most patterns exist to uphold them.
• SRP: one class, one job. OCP: extend without modifying. LSP: subclasses are substitutable.
• ISP: small interfaces over fat ones. DIP: depend on abstractions, not concretions.
• Learning patterns gives you a shared vocabulary and proven solutions.