Design Patterns Simplified: A Practical Guide to Core Principles and Key Patterns (Part-1)

SOLID Principles

One of the most significant “aha!” moments in my software engineering journey was discovering the SOLID principles. These five principles completely transformed how I approach designing classes and systems. They form the foundation of writing clean, maintainable, and scalable code. Each principle tackles a specific aspect of object-oriented design, and I’ve found that once you internalize them, they become second nature, making your code robust yet flexible.

Let’s break them down with easy-to-follow explanations and code snippets.

1. Single Responsibility Principle (SRP)

The Single Responsibility Principle states that a class should have one, and only one, reason to change. In other words, a class should do one thing and do it well. This makes classes more focused, easier to maintain, and more testable.

Example: Let’s take a simple example of a class that handles both user data and sends an email notification when the user registers. This violates SRP because it has two responsibilities: managing users and sending notifications.

Code Without SRP:

class User {
    public void register(String email) {
        // Register the user
        System.out.println("User registered: " + email);

        // Send a notification email
        sendEmail(email);
    }

    private void sendEmail(String email) {
        System.out.println("Sending email to: " + email);
    }
}

If we need to change the email-sending logic or add a different notification mechanism, we’ll have to modify this class. This violates SRP.

Code With SRP:

class User {
    public void register(String email) {
        System.out.println("User registered: " + email);
        NotificationService notificationService = new NotificationService();
        notificationService.sendEmail(email);
    }
}

class NotificationService {
    public void sendEmail(String email) {
        System.out.println("Sending email to: " + email);
    }
}

Here, the User class is only responsible for registering the user, while the NotificationService class is responsible for sending notifications. Each class has a single responsibility, making the code easier to extend and maintain.

2. Open/Closed Principle (OCP)

The Open/Closed Principle states that software entities (classes, modules, functions, etc.) should be open for extension but closed for modification. This means we should be able to add new functionality without changing existing code, thus reducing the risk of introducing bugs into a stable system.

Example: Let’s consider a class that calculates discounts based on user types.

Code Without OCP:

class DiscountCalculator {
    public double calculateDiscount(String userType, double price) {
        if (userType.equals("Regular")) {
            return price * 0.10;
        } else if (userType.equals("Premium")) {
            return price * 0.20;
        }
        return 0;
    }
}

If we want to add a new user type, like “VIP,” we’ll need to modify this class, which violates the Open/Closed Principle.

Code With OCP:

abstract class Discount {
    public abstract double applyDiscount(double price);
}

class RegularDiscount extends Discount {
    public double applyDiscount(double price) {
        return price * 0.10;
    }
}

class PremiumDiscount extends Discount {
    public double applyDiscount(double price) {
        return price * 0.20;
    }
}

class DiscountCalculator {
    public double calculateDiscount(Discount discount, double price) {
        return discount.applyDiscount(price);
    }
}

Now, if we want to add a new discount type (e.g., for VIP users), we can simply create a new class (VIPDiscount) without modifying the existing DiscountCalculator class.

3. Liskov Substitution Principle (LSP)

The Liskov Substitution Principle states that objects of a superclass should be replaceable with objects of a subclass without altering the correctness of the program. In simple terms, derived classes should be able to stand in for their base classes.

Example: Imagine we have a base class Bird with a method fly. If we create a subclass Penguin that cannot fly, it breaks the LSP.

Code Violating LSP:

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

class Penguin extends Bird {
    @Override
    public void fly() {
        throw new UnsupportedOperationException("Penguins can't fly!");
    }
}

Here, the Penguin class violates LSP because it can’t be used as a substitute for Bird without breaking functionality.

Code Complying With LSP:

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

class Sparrow extends Bird {
    @Override
    public void move() {
        System.out.println("Flying");
    }
}

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

By introducing the move method instead of fly, we ensure that all birds can be substituted without violating LSP.

4. Interface Segregation Principle (ISP)

The Interface Segregation Principle states that no client should be forced to depend on methods it doesn’t use. This principle encourages creating smaller, more specific interfaces rather than a large, general-purpose interface.

Example: Let’s say we have a Worker interface that defines several methods for a worker’s daily routine.

Code Without ISP:

interface Worker {
    void work();
    void eat();
}

class HumanWorker implements Worker {
    public void work() {
        System.out.println("Human working");
    }

    public void eat() {
        System.out.println("Human eating");
    }
}

class RobotWorker implements Worker {
    public void work() {
        System.out.println("Robot working");
    }

    public void eat() {
        // Robots don't eat, so this method doesn't make sense here
    }
}

The RobotWorker class is forced to implement the eat method, even though it doesn’t need it. This violates ISP.

Code With ISP:

interface Workable {
    void work();
}

interface Eatable {
    void eat();
}

class HumanWorker implements Workable, Eatable {
    public void work() {
        System.out.println("Human working");
    }

    public void eat() {
        System.out.println("Human eating");
    }
}

class RobotWorker implements Workable {
    public void work() {
        System.out.println("Robot working");
    }
}

Now, RobotWorker only implements the Workable interface, while HumanWorker can implement both Workable and Eatable, adhering to ISP.

5. Dependency Inversion Principle (DIP)

The Dependency Inversion Principle suggests that high-level modules should not depend on low-level modules. Instead, both should depend on abstractions. This reduces coupling between components and makes the system more modular.

Example: Consider a LightBulb class that’s tightly coupled with a Switch class.
Code Without DIP:

class LightBulb {
    public void turnOn() {
        System.out.println("Lightbulb on");
    }

    public void turnOff() {
        System.out.println("Lightbulb off");
    }
}

class Switch {
    private LightBulb bulb;

    public Switch(LightBulb bulb) {
        this.bulb = bulb;
    }

    public void toggle() {
        // Tightly coupled to LightBulb
        bulb.turnOn();
    }
}

Here, the Switch class directly depends on LightBulb, which makes it harder to extend the system (e.g., adding different types of lights).

Code With DIP:

interface Switchable {
    void turnOn();
    void turnOff();
}

class LightBulb implements Switchable {
    public void turnOn() {
        System.out.println("Lightbulb on");
    }

    public void turnOff() {
        System.out.println("Lightbulb off");
    }
}

class Switch {
    private Switchable device;

    public Switch(Switchable device) {
        this.device = device;
    }

    public void toggle() {
        device.turnOn();
    }
}

By introducing the Switchable interface, we decouple Switch from LightBulb, making it easy to swap out or extend with other devices (e.g., Fan, Heater).

The SOLID principles act as a guiding compass for writing clean, scalable, and maintainable code. By applying these principles, you’ll not only avoid common pitfalls in object-oriented design but also build systems that are flexible enough to grow and evolve.