Java – Strategy Pattern vs Delegates

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.

In your example, the code calling readFile is part of the Client constructor. That method is the "context" you are looking for. The strategy pattern does not need a "context class" literally, and at the first version of your code the strategy object (the "Reader" in your case) may reside just in a local variable. Especially when there is just one "strategic method" ("readFile") to be called.

However, if your codebase grows from one version to the next, it is not unlikely getting more and more "strategic" methods to be called, and the decision which strategy to apply and the performing of the "strategic methods" will happen at different times and at different places in your code. So you start to refactor them to keep the logic in one place. This will lead straightforward to an implementation looking similar to the diagram in your question.