Introduction:
In the previous article, we explored the importance of design patterns in software development and how they provide proven solutions to common problems. We discussed how choosing the right pattern is like selecting the appropriate tool from your toolbox. In this article, we'll dive deeper into the Strategy pattern and provide a practical, real-world example of its implementation using Java.

Real-World Example: E-commerce Shipping

Solving the Problem Without Using a Design Pattern
Let's consider the e-commerce application that needs to calculate shipping costs based on different shipping providers. Without using a design pattern, we might end up with a less flexible and maintainable solution. Here's how the implementation might look:

public class ShippingCalculator {
    public double calculateShippingCost(String provider, double weight) {
        if (provider.equals("Standard")) {
            return weight * 1.5;
        } else if (provider.equals("Express")) {
            return weight * 3.0;
        } else {
            throw new IllegalArgumentException("Unknown shipping provider");
        }
    }
}

// Usage
ShippingCalculator calculator = new ShippingCalculator();
double cost = calculator.calculateShippingCost("Standard", 5.0);
System.out.println("Shipping cost: $" + cost);

cost = calculator.calculateShippingCost("Express", 5.0);
System.out.println("Shipping cost: $" + cost);

Solving the Problem Using a Design Pattern

What is the Strategy Pattern?
The Strategy pattern is a behavioral design pattern that allows you to define a family of algorithms, encapsulate each one, and make them interchangeable. It lets the algorithm vary independently from clients that use it. The pattern consists of three main components:

Strategy: Defines a common interface for all supported algorithms.
Concrete Strategies: Implement the algorithm defined in the Strategy interface.
Context: Maintains a reference to a Strategy object and uses it to execute the algorithm.

Let's consider same e-commerce application that needs to calculate shipping costs based on different shipping providers. Each provider has its own algorithm for calculating the shipping cost. We can apply the Strategy pattern to encapsulate each shipping provider's algorithm separately, allowing for easy switching and maintenance.

Step-by-Step Implementation:

• 1 Define the Strategy interface:

public interface ShippingStrategy {
    double calculateCost(double weight);
}

• 2 Create concrete classes for each shipping provider, implementing the Strategy interface:

public class StandardShipping implements ShippingStrategy {
    @Override
    public double calculateCost(double weight) {
        return weight * 1.5;
    }
}

public class ExpressShipping implements ShippingStrategy {
    @Override
    public double calculateCost(double weight) {
        return weight * 3.0;
    }
}

• 3 Use the Strategy pattern in the main application code:

public class ShippingCalculator {
    private ShippingStrategy shippingStrategy;

    public void setShippingStrategy(ShippingStrategy strategy) {
        this.shippingStrategy = strategy;
    }

    public double calculateShippingCost(double weight) {
        return shippingStrategy.calculateCost(weight);
    }
}

// Usage
ShippingCalculator calculator = new ShippingCalculator();
calculator.setShippingStrategy(new StandardShipping());
double cost = calculator.calculateShippingCost(5.0);
System.out.println("Shipping cost: $" + cost);

calculator.setShippingStrategy(new ExpressShipping());
cost = calculator.calculateShippingCost(5.0);
System.out.println("Shipping cost: $" + cost);

Differences Between the Two Approaches

Without Design Pattern

Tight Coupling: The ShippingCalculator class is tightly coupled with the shipping providers. Any change in the shipping cost calculation logic requires modifying the ShippingCalculator class.
Lack of Flexibility: Adding a new shipping provider requires modifying the calculateShippingCost method, which can lead to errors and makes the code less flexible.
Maintainability Issues: The code is harder to maintain and extend because all the logic is in a single method.

With Strategy Pattern

Loose Coupling: The ShippingCalculator class is decoupled from the shipping providers. Each provider's algorithm is encapsulated in its own class.
Flexibility: Adding a new shipping provider is as simple as creating a new class that implements the ShippingStrategy interface.
Maintainability: The code is more modular and easier to maintain. Each shipping provider's logic is in its own class, making it easier to manage and update.

Benefits of Using Design Patterns

Proven Solutions: Design patterns provide proven, reliable solutions to common problems, reducing the need to reinvent the wheel.
Improved Communication: They offer a common vocabulary for developers to discuss solutions, making it easier to communicate and understand the design.
Maintainability: Patterns promote maintainability by encouraging modular and decoupled code.
Flexibility and Extensibility: Design patterns make it easier to extend and modify the system without affecting existing code.
Speed Up Development: By providing ready-made solutions, design patterns can speed up the development process.

Conclusion

The Strategy pattern is a powerful tool for encapsulating algorithms and making them interchangeable. By applying this pattern to the e-commerce shipping example, we achieved a flexible and maintainable solution that allows for easy switching between different shipping providers. Remember to consider the trade-offs and choose the pattern that best fits your project's requirements.
I hope this article has provided you with a clear understanding of the differences between solving a problem with and without a design pattern, and the benefits of using design patterns. Feel free to share your thoughts and experiences in the comments section below. Happy coding!