DEV Community: Heli Shah

Understanding Strategy Design Pattern: A Simple Guide

Heli Shah — Thu, 03 Jul 2025 22:40:43 +0000

Design patterns are essential tools in a software engineer's toolkit. They help solve common problems with proven solutions. Among the behavioral patterns, the Strategy Design Pattern stands out for its flexibility and ability to keep code clean and maintainable. In this blog post, we'll explore the Strategy Pattern, understand when to use it, and see a practical implementation in Java.

What is the Strategy Pattern?

The Strategy Pattern allows you to define a family of algorithms, encapsulate each one as a separate class, and make them interchangeable. Instead of hardcoding a behavior into a class, the behavior is pulled out and placed into separate strategy classes.

Category: Behavioral Design Pattern
Purpose: Select an algorithm's behavior at runtime.

When to Use the Strategy Pattern

You should consider using the Strategy Pattern when:

You have multiple related algorithms that vary only in behavior.
You need to switch algorithms at runtime.
You want to avoid multiple conditional statements like if or switch.
You want to adhere to the Open/Closed Principle (open for extension, closed for modification).

Real-World Analogy

Think of a navigation app. You can choose between different strategies to reach your destination:

Fastest Route
Shortest Distance
Avoid Tolls

Each of these is a different strategy for solving the same problem: navigation. The app lets you pick the strategy dynamically.

Structure of the Strategy Pattern

Strategy Interface: Common interface for all strategies.
Concrete Strategies: Implement the interface with specific behaviors.
Context: Maintains a reference to the strategy and delegates the behavior.

Java Implementation: Payment System

Let’s implement a payment system where the user can choose how to pay: via Credit Card, PayPal, or UPI.

1. Strategy Interface

public interface PaymentStrategy {
    void pay(double amount);
}

2. Concrete Strategies

public class CreditCardPayment implements PaymentStrategy {
    public void pay(double amount) {
        System.out.println("Paid ₹" + amount + " using Credit Card");
    }
}

public class PayPalPayment implements PaymentStrategy {
    public void pay(double amount) {
        System.out.println("Paid ₹" + amount + " using PayPal");
    }
}

public class UPIPayment implements PaymentStrategy {
    public void pay(double amount) {
        System.out.println("Paid ₹" + amount + " using UPI");
    }
}

3. Context Class

public class PaymentProcessor {
    private PaymentStrategy strategy;

    public PaymentProcessor(PaymentStrategy strategy) {
        this.strategy = strategy;
    }

    public void setStrategy(PaymentStrategy strategy) {
        this.strategy = strategy;
    }

    public void processPayment(double amount) {
        strategy.pay(amount);
    }
}

4.Usage

public class StrategyPatternDemo {
    public static void main(String[] args) {
        PaymentProcessor processor = new PaymentProcessor(new CreditCardPayment());
        processor.processPayment(2500.00);

        processor.setStrategy(new PayPalPayment());
        processor.processPayment(1200.00);

        processor.setStrategy(new UPIPayment());
        processor.processPayment(500.00);
    }
}

Output:

Paid ₹2500.0 using Credit Card
Paid ₹1200.0 using PayPal
Paid ₹500.0 using UPI

Benefits of Using Strategy Pattern

Flexibility: You can change the algorithm at runtime.
Clean Code: Avoids long if-else or switch statements.
Scalability: Easy to add new strategies without touching existing logic.
Testability: Each strategy can be tested independently.

Final Thoughts

The Strategy Pattern is ideal when you need different variations of an algorithm and want to keep your code modular and maintainable. It embraces composition over inheritance and aligns perfectly with SOLID principles.

Understanding and applying the Strategy Pattern in your Java applications can help you write better-designed, more testable, and maintainable code.

Ready to replace those messy if-else blocks with elegant strategies? Happy coding! 🚀

Understanding Factory Design Pattern: A Simple Guide

Heli Shah — Tue, 01 Jul 2025 23:58:52 +0000

"The name Factory itself suggests that it will create something for us."
That's exactly what it does—the Factory Method generates objects for us so that we don't have to instantiate them directly.

What is the Factory Design Pattern?

The Factory Pattern is a type of creational design pattern. As the name implies, it’s all about creating objects—but in a way that adds flexibility, scalability, and maintainability to your codebase.

Instead of writing code that instantiates classes directly using new, you delegate that responsibility to a factory method. This method encapsulates the logic of choosing which object to create and returns it, hiding the instantiation details from the client.

Why Should You Use the Factory Pattern?

Let’s consider a real-world analogy. When you go to a car showroom, you don’t build your car—you tell the representative what kind of car you want, and they bring it to you. You use the car; you don’t care how it was built.

The Factory pattern works the same way:

You request an object.

The factory creates it and gives it to you.

You use it without worrying about how it was made.

Benefits:

Decouples object creation from its usage.
Supports polymorphism, enabling easy extension.
Makes your code open for extension but closed for modification.
Centralizes creation logic, making maintenance easier.

Structure of the Factory Pattern:

At a high level, here’s how the Factory pattern is structured:

Product Interface/Abstract Class – common interface for all products.
Concrete Products – specific implementations.
Creator/Factory Class – contains the factory method that returns a product.

Real-World Example: Ride Sharing App (Uber, Lyft):

Imagine you're building a ride-sharing app like Uber or Lyft. Users can choose different types of rides: Standard, Luxury, or SUV.

Rather than having the app directly instantiate each ride type using new StandardRide(), new LuxuryRide(), etc., we use a RideFactory to handle that logic.

Problem
You want to avoid hardcoding logic like:

if (rideType.equals("standard")) {
    ride = new StandardRide();
}

throughout the app. Instead, centralize and abstract it using a Factory.

Applying the Factory Pattern

Step 1: Common Interface

public interface Ride {
    void bookRide();
}

Step 2: Concrete Ride Types

public class StandardRide implements Ride {
    public void bookRide() {
        System.out.println("Standard ride booked. Arriving in 5 minutes.");
    }
}

public class LuxuryRide implements Ride {
    public void bookRide() {
        System.out.println("Luxury ride booked. A premium car is on its way.");
    }
}

public class SUVRide implements Ride {
    public void bookRide() {
        System.out.println("SUV ride booked. Perfect for group travel.");
    }
}

Step 3: The Factory Class

public class RideFactory {

    public Ride getRide(String rideType) {
        if (rideType == null) return null;

        switch (rideType.toLowerCase()) {
            case "standard":
                return new StandardRide();
            case "luxury":
                return new LuxuryRide();
            case "suv":
                return new SUVRide();
            default:
                throw new IllegalArgumentException("Unknown ride type");
        }
    }
}

Step 4: Client Code

public class Main {
    public static void main(String[] args) {
        RideFactory factory = new RideFactory();

        Ride ride1 = factory.getRide("luxury");
        ride1.bookRide();  // Luxury ride booked...

        Ride ride2 = factory.getRide("suv");
        ride2.bookRide();  // SUV ride booked...
    }
}

When Should You Use It?

When your code needs to create multiple types of objects that share a common interface.
When you want to isolate object creation logic from business logic.
When the creation process is complex or might change in the future.

When Not to Use It?

If you only have one class and object creation is straightforward, a factory may be overkill.
In performance-critical code paths, extra abstraction might add unnecessary overhead.

Wrapping Up:

The Factory Design Pattern is a powerful tool in your OOP toolkit. It simplifies object creation and helps you write cleaner, more modular, and more maintainable code. Like any design pattern, the key is knowing when to use it.

Next time you’re faced with multiple object types and a need for flexible instantiation, remember:

“Don’t call the constructor—let the factory handle it.”

Understanding Singleton Design Pattern: A Simple Guide

Heli Shah — Thu, 26 Jun 2025 00:07:24 +0000

What is Singleton Pattern?

Imagine you have a TV remote at home. You don't need 10 remotes for the same TV, right? One remote is enough for everyone in the family to use.

The Singleton pattern works the same way - it ensures that a class has only one instance and everyone uses that same instance.

Why Do We Need Singleton?

Think about these real-world examples:

Database connection - You don't want 100 connections to the same database
Printer - Multiple print jobs should go to the same printer
Settings/Configuration - Your app should have one set of settings, not multiple copies

Simple Example

Let's say we're building a Logger class to write logs to a file. We want only one logger in our entire application.

public class Logger {
    // Step 1: Create a private static instance
    private static Logger instance = null;

    // Step 2: Make constructor private (no one can create new instances)
    private Logger() {
        System.out.println("Logger created!");
    }

    // Step 3: Provide a public method to get the instance
    public static Logger getInstance() {
        if (instance == null) {
            instance = new Logger();
        }
        return instance;
    }

    // Your actual methods
    public void log(String message) {
        System.out.println("LOG: " + message);
    }
}

How to Use It

public class Main {
    public static void main(String[] args) {
        // Get the logger instance
        Logger logger1 = Logger.getInstance();
        Logger logger2 = Logger.getInstance();

        // Both are the same instance!
        System.out.println(logger1 == logger2); // prints: true

        logger1.log("Hello World!");
        logger2.log("This is the same logger!");
    }
}

The Problem with Above Code

The above code has a problem - it's not thread-safe. If two threads call getInstance() at the same time, we might create two instances.

Better Solutions

1. Thread-Safe Version

public class ThreadSafeLogger {
    private static ThreadSafeLogger instance = null;

    private ThreadSafeLogger() {}

    // Add 'synchronized' keyword
    public static synchronized ThreadSafeLogger getInstance() {
        if (instance == null) {
            instance = new ThreadSafeLogger();
        }
        return instance;
    }
}

2. Eager Initialization (Recommended for Beginners)

public class EagerLogger {
    // Create instance immediately when class loads
    private static final EagerLogger instance = new EagerLogger();

    private EagerLogger() {}

    public static EagerLogger getInstance() {
        return instance; // Just return the already created instance
    }
}

3. Enum Singleton (Best Approach)

public enum LoggerEnum {
    INSTANCE;

    public void log(String message) {
        System.out.println("LOG: " + message);
    }
}

// Usage
LoggerEnum.INSTANCE.log("Hello from enum singleton!");

Advantages

Memory Efficient - Only one instance exists

Global Access - Can be accessed from anywhere

Lazy Loading - Created only when needed (in some implementations)

Disadvantages

Hard to Test - Difficult to mock in unit tests

Global State - Can make code harder to understand

Threading Issues - Need to handle multiple threads carefully

When to Use Singleton

Good for:

Database connections
File/Network managers
Logging systems
Configuration settings
Cache managers

Avoid for:

Regular business objects
When you need multiple instances later
When testing is important

Key Takeaways

Singleton ensures only one instance of a class
Make the constructor private
Provide a public static method to get the instance
For beginners, use Eager Initialization
For advanced users, Enum Singleton is the best

Final Tip

Don't overuse Singleton! It's often called an "anti-pattern" because it can make your code harder to test and maintain. Use it only when you truly need exactly one instance of something.

Remember: One remote, one TV. One singleton, one purpose!

Happy coding! 🚀

Mastering Design Patterns: The foundation

Heli Shah — Fri, 20 Jun 2025 22:31:57 +0000

Ever looked at your code and thought, “There must be a better way to organize this.” That’s where design patterns come in.

In this post, we will explore what design patterns are, why they matter, and how they are categorized.

What Are Design Patterns?

Design patterns are proven, reusable solutions to common software design problems. Think of them like templates or blueprints—not code that you copy and paste, but rather ideas and structures that guide you in solving recurring problems in a clean, efficient, and maintainable way.

The Three Main Categories of Design Patterns:

Design patterns generally fall into three broad categories, each addressing a different kind of software design problem:

1. Creational Patterns
These deal with object creation mechanisms, trying to create objects in a manner that is suitable to the situation. They help make a system independent of how its objects are created, composed, and represented.

Examples: Singleton, Factory Method, Builder, Abstract Factory, Prototype

2. Structural Patterns
These focus on how classes and objects are composed to form larger structures. They help ensure that if one part of a system changes, the entire system doesn't need to do the same.

Examples: Adapter, Composite, Proxy, Decorator, Bridge, Facade

3. Behavioral Patterns
These are concerned with communication between objects, focusing on the responsibilities and the flow of control in a program.

Examples: Observer, Strategy, Command, State, Iterator, Mediator

What's Coming Next?

In the upcoming posts, I’ll break down each design pattern—complete with real-world analogies, use cases, pros & cons, and practical examples in code.

Whether you’re a beginner developer or someone brushing up on architectural skills, this series will help you think more clearly about software design.

Let’s Talk!

Have you used any design patterns in your projects? Or do they still feel abstract and academic? Drop a comment below—I’d love to hear your thoughts or questions!