Design Patterns – Are First-Class Functions a Substitute for the Strategy Pattern?

design-patternsfunctionsobject-oriented

The Strategy design pattern is often regarded as a substitute for first-class functions in languages that lack them.

So for example say you wanted to pass functionality into an object. In Java you'd have to pass in the object another object which encapsulates the desired behavior. In a language such as Ruby, you'd just pass the functionality itself in the form of an anonymous function.

However I was thinking about it and decided that maybe Strategy offers more than a plain anonymous function does.

This is because an object can hold state that exists independently of the period when it's method runs. However an anonymous function by itself can only hold state that ceases to exist the moment the function finishes execution.

In an object-oriented language that supports first-class functions, does the strategy pattern have any advantage over using functions?

Best Answer

When the language supports references to function (Java does since version 8), these are often a good alternative for strategies, because they usually express the same thing with less syntax. However, there are some cases where a real object can be useful.

A Strategy interface can have multiple methods. Let's take an interface RouteFindingStragegy as example, which encapsulates different route finding algorithms. It could declare methods like

Route findShortestRoute(Node start, Node destination)
boolean doesRouteExist(Node start, Node destination)
Route[] findAllPossibleRoutes(Node start, Node destination)
Route findShortestRouteToClosestDestination(Node start, Node[] destinations)
Route findTravelingSalesmanRoute(Node[] stations)

which then would all be implemented by the strategy. Some route-finding algorithms might allow internal optimizations for some of these use-cases and some might not, so the implementor can decide how to implement each of these methods.

Another case is when the strategy has an inner state. Sure, in some languages closures can have inner state, but when this inner state gets very complex, it often becomes more elegant to promote the closure to a full-fledged class.

Related Solutions

Java – Modified Strategy Design Pattern

You need to clarify your strategy.

It all depends on how you use your algorithms. For your client class to use different strategy implementations interchangeably, they all need to have a common abstraction. If they don't follow the same interface, maybe what you need are different abstractions.

I've used configurable strategies before, where you parameterize the concrete classes on construction:

interface Strategy {
  int calculate();
}

class ConcreteStrategyThatNeedsAParameter implements Strategy {
  private final int param;
  public ConcreteStrategyThatNeedsAParameter(int param) {
    this.param = param;
  }
  public int calculate() { 
    // uses param...
  }
}

Now, someone still needs to create an instance of this class and pass it to your client. But your client still only needs to know about the Strategy interface.

It also works if your strategy method takes parameters, but then your client knows about those parameters and passes them to all implementations it works with.

Design Patterns – Should Strategy Objects Have State?

I know I'm being pedantic here, but all objects can have state. The question is whether or not they should have state.

The answer to that question for strategies is the same as the answer for every other kind of inheritance relationship: Yes, as long as you're not violating the Liskov Substitution Principle.

The point of a strategy (or really any other inheritance-based design pattern) is that the caller/owner doesn't care about the implementation. So if the state is initialized either internally or through an instance constructor, and completely self-managed, then state is fine. On the other hand, if the outside world is supposed to be aware of this instance-specific state, then you've got a problem.

In a nutshell, if you find yourself needing to make this state public, then you've probably got a poor design; doubly so if you find yourself doing typecasts from the interface. But private state is, well, private; the whole point of patterns like Strategy is that the caller really doesn't care.

One other thing: Try to avoid sequential coupling. Even though it's OK for the strategy to have state, if the behaviour of the strategy depends significantly on that state then you are wading into dangerous territory, because you have no idea who else is going to try to use this strategy in the future and be unaware of the correct order of operations, so to speak.

Best Answer

Related Solutions

Java – Modified Strategy Design Pattern

Design Patterns – Should Strategy Objects Have State?

Related Topic