How to implement a large algorithm with mostly unrelated steps while maintaining cohesion

Question

I want to implement something similar to the algorithm described here. I don't even know if "algorithm" is the right word, since many of the steps are considered to be algorithms themselves. What I've done in the past in situations like this is to encapsulate each step in a private method of a class, and then provide a public method that calls each of the steps in order. However, I feel like this violates the design principle of cohesion. The only way the steps relate to each other is that they share data, and they are called one after another. Is there a design pattern that decouples these operations from each other? Or is the way I described above the only way to approach this?

Answer 1

For smaller methods, you design might be ok. For bigger methods, if each of the steps is an algorithm itself, put each of it into a class of its own, where the class has one public method. This forces you to make the dataflow explicit, and it allows you to write individual unit tests for each sub-algorithms.