DEV Community

Karl Heinz Marbaise
Karl Heinz Marbaise

Posted on

Spring Boot: Strategy Design Pattern - Convenience and Limitation

You might have already used the strategy pattern in relationship with Spring Boot where it is very convenient to use.

You simply define an interface for example (I use the prefixing I only in these examples for clarity):

public interface IOneStrategy {
  void executeTheThing();
}
Enter fullscreen mode Exit fullscreen mode

Define some implementations like this:

@Service("FIRST")
public class OneStrategyFirst implements IOneStrategy {

  @Override
  public void executeTheThing() {
    System.out.println("OneStrategyFirst.executeTheThing");
  }
}
Enter fullscreen mode Exit fullscreen mode

Now you can simply implement a service which will execute the appropriate strategy based on the given name which looks similar like this:

@Service
public class ExecuteStrategyOne {
  private Map<String, IOneStrategy> strategies;

  public ExecuteStrategyOne(Map<String, IOneStrategy> strategies) {
    this.strategies = strategies;
  }

  public void executeStrategyOne(String name) {
    if (!strategies.containsKey(name)) {
      throw new IllegalArgumentException("The strategy " + name + " does not exist.");
    }
    strategies.get(name).executeTheThing();
  }

}
Enter fullscreen mode Exit fullscreen mode

In real world you make several implementations of the strategy interface like OneStrategyFirst, OneStrategySecond and OneStrategyThird. Sometimes the usage is to use the parameter of executeStrategyOne which is provided by a REST API or some other domain specific code which needs different implementations.

The convenience here is that Spring Boot (Spring Framework to be more accurate) handles the injection of the different implementation into the strategies Map within ExecuteStrategyOne via the constructor. This results in a Map where the key is the value which is given by @Service("FIRST") and the value of the map contains an instantiates class of every implementation of the interface IOneStrategy which can be found.

Really convenient.

In real life it happens that you need to have a different strategy which use the same keys as FIRST, SECOND and THIRD in the examples? Let us define the following:

@Service("FIRST")
public class TwoStrategyFirst implements ITwoStrategy {

  @Override
  public void executeTheThing() {
    System.out.println("TwoStrategyFirst.executeTheThing");
  }
}
Enter fullscreen mode Exit fullscreen mode

If you try to start that Spring Boot application you will see an exception like this:

Caused by: org.springframework.context.annotation.ConflictingBeanDefinitionException: 
Annotation-specified bean name 'FIRST' for bean class [com.soebes.examples.strategies.functions.two.TwoStrategyFirst] 
conflicts with existing, non-compatible bean definition of same name and class 
[com.soebes.examples.strategies.functions.one.OneStrategyFirst]
    at org.springframework.context.annotation.ClassPathBeanDefinitionScanner.checkCandidate(ClassPathBeanDefinitionScanner.java:349) ~[spring-context-5.2.9.RELEASE.jar:5.2.9.RELEASE]
    at org.springframework.context.annotation.ClassPathBeanDefinitionScanner.doScan(ClassPathBeanDefinitionScanner.java:287) ~[spring-context-5.2.9.RELEASE.jar:5.2.9.RELEASE]
Enter fullscreen mode Exit fullscreen mode

So what can we do to solve the problem without losing much of the convenience which Spring Boot provides us here?

First we have to define in each of the strategy implementation class the annotations like this:

@Service
@Qualifier("FIRST")
public class TwoStrategyFirst implements ITwoStrategy {

  @Override
  public void executeTheThing() {
    System.out.println("TwoStrategyFirst.executeTheThing");
  }
}
Enter fullscreen mode Exit fullscreen mode

By using the key in a different annotation we prevent the duplication of the bean names in contradiction to use @Service("FIRST") instead. The usage of @Qualifier("FIRST") gives us a criteria to handle that different.

Now we have to change the ExecuteStrategyOne class like the following:

@Service
public class ExecuteStrategyOne {

  private Map<String, IOneStrategy> strategies;

  public ExecuteStrategyOne(List<IOneStrategy> strategies) {
    this.strategies = strategies.stream()
        .collect(
            toMap(k -> k.getClass().getDeclaredAnnotation(Qualifier.class).value(), 
                  Function.identity()));
  }
  ...
}
Enter fullscreen mode Exit fullscreen mode

I would like to emphasis the usage of the constructor parameter List<IOneStrategy> strategies instead of the previously used Map<String, IOneStrategy> strategies which is a convenience to get a list of all implementations off the given interface into that list by Spring Boot. Now we need to translate that into a map with the key we have defined by using @Qualifier annotation. The whole thing can be solved by a stream like this:

this.strategies = strategies
  .stream()
  .collect(
    Collectors.toMap(k -> k.getClass().getDeclaredAnnotation(Qualifier.class).value(), 
                     Function.identity()));
Enter fullscreen mode Exit fullscreen mode

We go through the implementations and extract the annotation @Qualifier and read out the value() which is the key we want to have. We collect the result by using the Collectors.toMap into a Map and assign the result to the instance variable private Map<String, IOneStrategy> strategies;.
Depending on your need it is of course possible to define the instance variable as final and you can create an unmodifiable map by using the appropriate Collectors.toUnmodifiableMap instead of the toMap(..) if needed.

So with a few changes in the code we can easily solve the problem of having different strategies which using the same keys in our code.

The given code is available as a full working example on GitHub.

Latest comments (2)

Collapse
 
jouo profile image
Jashua

Thanks for sharing, Karl!

I have a question if you don't mind, is the Strategy pattern an implementation of the Dependency Inversion principle?

Collapse
 
khmarbaise profile image
Karl Heinz Marbaise

Not that I know. Just a design pattern mentioned in en.wikipedia.org/wiki/Design_Patterns ... maybe a little bit based on the part where an interface is used en.wikipedia.org/wiki/Dependency_i...