Avoiding If-Else: Advanced Approaches and Alternatives

Mostly, developers make use of if-else statements to cater to differing circumstances. Even so, this could prove itself quite troublesome especially when more conditions arise. Putting additional business needs into these chains might cause errors while making the code more complicated than necessary. It is advisable that we anticipate eventually creating solutions that could change or grow without being difficultly updated in order not only to ensure the robustness of one’s system but also to enable its adaptation within unforeseen circumstances. Our codes will then remain potent and readily adaptable to the needs ahead us in this case.

In this article, we’ll delve into methods for managing functions in a calculator using Java in all examples. The aim is to enhance the processing of operations (such as addition, subtraction, multiplication, and division) in our coding. We’ll incorporate techniques by using a sample calculator that receives a request with an operation type and two values, including if-else statements, switch cases, and the strategy design pattern. The main focus will be on describing the concepts and benefits of each method.

Request Structure

First, let’s define the request structure, which will be used to demonstrate different approaches:

public class CalculationRequest {
 private final Operation operation;
 private final int first;
 private final int second;

 // Constructor, getters, and setters
}

enum Operation{
  ADD,
  SUBTRACTION,
  DIVISION,
  MULTIPLICATION;  
}

If-Else Statement

If-else statements are one of the simplest and most commonly used constructs for handling conditions in programming. They allow the execution of a specific block of code depending on whether a condition is met. In the context of a calculator, if-else statements can be used to handle various operations like addition, subtraction, multiplication, and division. Consider the following example demonstrating the use of if-else statements for performing these operations:

public static Integer calculate(CalculationRequest request) {
 var first = request.getFirst();
 var second = request.getSecond();
 var operation = request.getOperation();

if (Operation.ADD.equals(operation)) {
   return first + second;
 } else if (Operation.SUBTRACTION.equals(operation)) {
   return first - second;
 } else if (Operation.DIVISION.equals(operation)) {
   if (second == 0) {
     throw new IllegalArgumentException("Can't be zero");
   }
   return first / second;
 } else if (Operation.MULTIPLICATION.equals(operation)) {
   return first * second;
 } else {
   throw new IllegalStateException("Operation not found");
 }
}

Pros

• Simplicity: Easy to understand and implement.
• Clarity: The code clearly shows what happens in each condition.

Cons

• Maintenance: Changing logic requires modifications in multiple places, increasing the risk of errors. For example, if a new operation is added, another condition must be added to the if-else chain, increasing the risk of missing a condition. Numerous changes in different places also complicate debugging and testing the code.
• Scalability: Adding new operations requires changing existing code, violating the open/closed principle (OCP) from SOLID. Each new condition requires modifying existing code, making it less flexible and resilient to changes. This can lead to increased technical debt and reduced code quality in the long term.

Switch Statement

Switch statements can be more readable and convenient in some cases compared to if-else chains. They allow better structuring of the code and avoid long chains of conditions. Let’s consider using switch statements.

public static Integer calculate(CalculationRequest request) {
 var first = request.getFirst();
 var second = request.getSecond();
 var operation = request.getOperation();

return switch (operation) {
   case ADD -> first + second;
   case SUBTRACTION -> first - second;
   case DIVISION -> {
       if (second == 0) {
       throw new IllegalArgumentException("Can't be zero");
     }
     yield first / second;
   }
   case MULTIPLICATION -> first * second;
 };
}

Pros

• Readability: More structured compared to a long if-else chain. The code becomes more compact and easy to read.
• Simplification: Clear separation of different cases, making the code neater.

Cons

• Scalability: Like if-else, adding new operations requires changing existing code, violating the open/closed principle (OCP) from SOLID.
• Flexibility: Switch statements can be less flexible than some other approaches. For example, they do not easily integrate complex logic or states that may be necessary in some operations. This makes them less suitable for advanced use cases where more complex processing is required.

Strategy Pattern

The strategy pattern allows defining a family of algorithms, encapsulating each one, and making them interchangeable. This allows clients to use different algorithms without changing their code. In the context of a calculator, each operation (addition, subtraction, multiplication, division) can be represented by a separate strategy. This improves the extensibility and maintainability of the code, as new operations can be added without changing existing code.

Pros

• Scalability: Easy to add new strategies without changing existing code. This is especially useful in situations where new functions need to be supported or added in the future.
• SOLID Support: The pattern supports the single responsibility principle (SRP), as each strategy is responsible for its specific operation. It also supports the open/closed principle (OCP), as new strategies can be added without changing existing classes.
• Flexibility: Algorithms can be easily changed at runtime by substituting the appropriate strategy. This makes the system more flexible and adaptable to changing requirements.

Cons

• Complexity: Can add additional complexity to the code, especially when implementing multiple strategies. The number of classes increases, which can make project management difficult.

Let’s look at different implementation options:

Enum

In this example, we create an enum Operation with an abstract apply method. Each enum element corresponds to an implementation of this method. This encapsulates the logic of each operation in separate enumeration elements, making the code more organized and maintainable.

public enum Operation {
    ADD {
        @Override
        Integer apply(int first, int second) {
            return first + second;
        }
    },
    SUBTRACTION {
        @Override
        Integer apply(int first, int second) {
            return first - second;
        }
    },
    DIVISION {
        @Override
        Integer apply(int first, int second) {
            if (second == 0) {
                throw new IllegalArgumentException("Can't be zero");
            }
            return first / second;
        }
    },
    MULTIPLICATION {
        @Override
        Integer apply(int first, int second) {
            return first * second;
        }
    };

  abstract Integer apply(int first, int second);
}

Usage:

public static Integer calculate(CalculationRequest request) {
    var first = request.getFirst();
    var second = request.getSecond();
    var operation = request.getOperation();
    
    return operation.apply(first, second);
}

Map of Objects

The OperationStrategy interface defines the apply method to be implemented for each operation, creating a single contract for all operations, simplifying the addition of new strategies.

public interface OperationStrategy { 
 Integer apply(int first, int second); 
}

Each operation is implemented as a separate class that implements the OperationStrategy interface. Each class implements the apply method to perform the corresponding operation.

class AddOperationStrategy implements OperationStrategy {
    @Override
    public Integer apply(int first, int second) {
        return first + second;
    }
}

class SubtractionOperationStrategy implements OperationStrategy {
    @Override
    public Integer apply(int first, int second) {
        return first - second;
    }
}

class DivisionOperationStrategy implements OperationStrategy {
    @Override
    public Integer apply(int first, int second) {
        if (second == 0) {
            throw new IllegalArgumentException("Can't be zero");
        }
        return first / second;
    }
}

class MultiplicationOperationStrategy implements OperationStrategy {
    @Override
    public Integer apply(int first, int second) {
        return first * second;
    }
}

We create a map STRATEGY_OBJECT_MAP where the keys are values of the Operation enum, and the values are the corresponding OperationStrategy implementations. This allows for the quick finding and use of the necessary strategy for each operation.

public static final Map<Operation, OperationStrategy> STRATEGY_OBJECT_MAP =
            Map.ofEntries(
                    Map.entry(Operation.ADD, new AddOperationStrategy()),
                    Map.entry(Operation.SUBTRACTION, new SubtractionOperationStrategy()),
                    Map.entry(Operation.DIVISION, new DivisionOperationStrategy()),
                    Map.entry(Operation.MULTIPLICATION, new MultiplicationOperationStrategy())
            );

The method retrieves the necessary strategy from the map and performs the operation by calling the apply method.

public static Integer calculate(CalculationRequest request) {
        var first = request.first();
        var second = request.second();
        var operation = request.operation();

        return STRATEGY_OBJECT_MAP.get(operation).apply(first, second);
    }

Map of Functions

This approach uses functional interfaces for each operation and creates a map where keys are operations, and values are functions. This avoids creating separate classes for each strategy, simplifying the code and making it more compact.

public static final Map<Operation, BiFunction<Integer, Integer, Integer>> STRATEGY_FUNCTION_MAP;

static {
    STRATEGY_FUNCTION_MAP = Map.ofEntries(
        Map.entry(Operation.ADD, (first, second) -> first + second),
        Map.entry(Operation.SUBTRACTION, (first, second) -> first - second),
        Map.entry(Operation.DIVISION, (first, second) -> {
            if (second == 0) {
                throw new IllegalArgumentException("Can't be zero");
            }
            return first / second;
        }),
        Map.entry(Operation.MULTIPLICATION, (first, second) -> first * second)
    );
}
public static Integer calculate(CalculationRequest request) {
    var first = request.getFirst();
    var second = request.getSecond();
    var operation = request.getOperation();
    
    return STRATEGY_FUNCTION_MAP.get(operation).apply(first, second);
}

Using a map of functions is quite suitable in cases when you need to implement a set of operations as quickly and easily as possible without creating separate classes for each. However, object strategies fit better in more complex scenarios.

Conclusion

Every method has its advantages and disadvantages that need to be considered in software development decisions. If-else switch statements are straightforward and user-friendly at first but become challenging to organize as the number of conditions grows. They don’t adapt well to changes and make it difficult to incorporate functions without altering the codebase.

The strategy pattern provides an adaptable approach to managing operations while adhering to SOLID principles. This makes it simple to incorporate operations without disrupting code, promoting code maintenance and scalability. Moreover, it enables adaptation to evolving business requirements without strain. Although initially complex, the benefits of its extendable code base prove worthwhile.