Don’t use if-else blocks anymore! Use Strategy and Factory Pattern Together

As we move forward in a project, lost in if-else blocks, struggling with complex conditions and repetitive code, we look for a solution. But why should we be stuck in if-else blocks? In this article, let’s discover the way to get rid of if-else confusion together with Strategy and Factory patterns.

Problem: If-Else Confusion

Let’s say you are developing an e-commerce application and you need to support different payment methods like credit card, debit card and cryptocurrency. You start with if-else blocks to process payments:

public class PaymentService {

    public void processPayment(String paymentType) {
        if (paymentType.equals("CREDIT_CARD")) {
            System.out.println("Processing credit card payment...");
        } else if (paymentType.equals("DEBIT_CARD")) {
            System.out.println("Processing debit card payment...");
        } else if (paymentType.equals("CRYPTO")) {
            System.out.println("Processing crypto payment...");
        } else {
            throw new IllegalArgumentException("Invalid payment type");
        }
    }
}

While it may seem simple at first, as payment methods increase, so will the if-else complexity. A new payment method means adding a new condition. The result is a pile of code that is difficult to manage. And this method is contrary to the Open-Closed Principle.

But, we can use the both Strategy and Factory patterns to solve this problem.

First, let’s create an enum:

public enum PaymentType {
    CREDIT_CARD,
    DEBIT_CARD,
    CRYPTO
}

Solution: Cleaning with Strategy Pattern

public interface PaymentStrategy {
    void pay(PaymentRequest request);
}

public class CreditCardPayment implements PaymentStrategy {
    @Override
    public void pay(PaymentRequest request) {
        System.out.println("Processing $type payment".replace("$type", String.valueOf(request.getPaymentType())));
    }
}

public class DebitCardPayment implements PaymentStrategy {
    @Override
    public void pay(PaymentRequest request) {
        System.out.println("Processing $type payment".replace("$type", String.valueOf(request.getPaymentType())));
    }
}

public class CryptoPayment implements PaymentStrategy {
    @Override
    public void pay(PaymentRequest request) {
        System.out.println("Processing $type payment".replace("$type", String.valueOf(request.getPaymentType())));
    }
}

At this stage, a separate strategy for each payment method is implemented from a common interface. Now, with Factory Pattern, we will decide which strategy to choose.

Step 2: Choosing Strategy with Factory Pattern

In this step, we can make the Factory Pattern cleaner and optimized with EnumMap.

public class PaymentFactory {
    private static final Map<PaymentType, PaymentStrategy> strategies = new EnumMap<>(PaymentType.class);

    static {
        strategies.put(PaymentType.CREDIT_CARD, new CreditCardPayment());
        strategies.put(PaymentType.DEBIT_CARD, new DebitCardPayment());
        strategies.put(PaymentType.CRYPTO, new CryptoPayment());
    }

    public static PaymentStrategy getPaymentStrategy(PaymentType paymentType) {
        PaymentStrategy strategy = strategies.get(paymentType);

        if (Objects.isNull(strategy))
            throw new IllegalArgumentException("Strategy not found");

        return strategy;
    }
}

Last Step: Service Class Reorganization

Now, let’s use what we have done.

public class PaymentService {

    public void processPayment(PaymentRequest request) {
        // Don't forget to check objects if null!
        if (Objects.isNull(request) || Objects.isNull(request.getPaymentType())
            throw new IllegalArgumentException("Request can not be null!");
        PaymentStrategy strategy = PaymentFactory.getPaymentStrategy(request.getPaymentType());

        strategy.pay(request);
    }
}

As it is, we don’t need any if-else blocks for payment processing. Thanks to Strategy and Factory Patterns, our code is cleaner, modular and extensible.

Why Should We Use This Patterns?

1. Extensibility: Adding a new payment method only requires a new class and a few lines of code.
2. Readability: By using strategies and factory instead of if-else blocks, you make your code more understandable and manageable.
3. Maintainability: With the strategy and factory pattern, changes to the code can be made without affecting other pieces of code.

Conclusion: From Confusion to Clarity

If you are working on a growing project, you shouldn’t use if-else blocks. Strategy and Factory patterns are perfect solutions to make your code cleaner, modular and maintainable.

As you can see in this article, using design patterns instead of if-else blocks to manage payment transactions makes the project more developable and improves the readability of the code. Try these patterns in your next project instead of using if-else blocks.

...

Thank you for reading my article! If you have any questions, feedback or thoughts you would like to share, I would love to hear them in the comments.

You can follow me on dev.to for more information on this topic and my other posts.

Thank you!👨‍💻🚀

To follow me on LinkedIn: https://www.linkedin.com/in/tamerardal/
Medium: Don’t use if-else blocks anymore! Use Strategy and Factory Pattern Together

Comments

[Alex Lohr]

I know this pattern under the name of branchless programming - the factory pattern is usually an OOP pattern where you define objects through methods, ie. new MyProduct().color(Colors.Blue).size(Size.XL).build().

[Boris]

That sounds like a version of the builder pattern to me, might be mistaken tho.

[Mahmoud Alaskalany]

That is a builder pattern

[Parables]

Great article but the title is a bit of an over-statement....
It sounds like if-else statements are a terrible thing...

This is not a silver bullet and for newbies reading this, don't go refactoring all your if-else blocks with this...

Understanding and mastering Design Patterns is a skill every developer needs to learn but most importantly, knowing when to use the right tool for the right job.

Sometimes, a simple if-else statement is the best solution... Know when to refactor

[Nozibul Islam]

Great article! Your explanation of how to replace if-else blocks with the Strategy and Factory patterns is clear and practical. The use of enums and EnumMap for organizing payment strategies is a clever approach that enhances both maintainability and readability. It's a perfect example of applying design patterns to create a more scalable solution in software development. I'm definitely inspired to implement this in my own projects!

Suggestion:
Consider adding a section that discusses potential pitfalls or challenges when implementing these patterns. For instance, it could be helpful to address how to manage dependencies between payment strategies or how to handle exceptions in a way that maintains clarity and avoids overly complex error handling.

[Tamer Ardal]

Thanks for your suggestion 🙂

[Khang]

Why does comment sound like AI to me? 🤔

[Maximilian Lenhardt]

I like this pattern, much more concise.

I would like to suggest a little improvement: I would use a switch Statement on the payment type instead of the map inside the PaymentFactory. Then you just get a compile error because a case is missing here if you happen to add another payment type. The map will fail at runtime :)

[Oscar]

Just a heads up that you can add highlighting to the code blocks if you'd like. Just change:

... to specify the language:

More details in our editor guide!

[Tamer Ardal]

Wow thanks, I didn't know that

[Vincent A. Cicirello]

Your PaymentFactory class isn't a factory. In the factory pattern, a factory method instantiates new object instances. In your example, the getPaymentStrategy method returns one of three pre-existing objects depending on payment type. Call that method again with same payment type and you get same payment strategy instance. This isn't a factory.

[John Peters]

I recall reading something similar to this on CodeProject 15 years ago. Was interested then but never implemented it. Today I find it rare to have huge if then or switch statements. Thanks for reminding me....

[DotNet Full Stack Dev]

@tamerardal Nice article! Its very pin to the point and great explanation too.
I tried similar article, with little advanced by adding selection of

• card(bankcard1, bankcard2..etc),

• UPI (upi1,upi2... etc),

• online banking (online banking1, onlinebanking2.. etc)

Have a look and add your thoughts and suggestions
Mastering Multiple Payment Gateways with Strategy and Abstract factory Combo

[CitronBrick]

You can use the below syntax to enable syntax highlighting in Dev.to

triplebacktick java
code
triplebacktick

[Gregory Gaines]

I wouldn't say never use if/else. What if inside credit card payments you have chip, tap, swipe, Google Pay, Apple Pay.

Now we have ChipCardPayment, TapCardPayment, SwipeCardPayment, GooglePayCardPayment, ApplePayCardPayment.

If you don't use if/else your're stuck creating a class for every condition. What about non oop languages, they won't be able to fully follow this principle.