Iterating over a list of types

Question

I find myself doing this sort of thing from time to time, and I wonder if it's a design smell, or if there's a better design pattern I can use.

There's a process with a number of steps that is known at compile time, but is likely to change down the road. I capture the commonality in an abstract Step class, write a StepLister that returns a list of steps, one for each derived class of Step, and then a StepsRunner which calls StepLister, then iterates over the list and runs each step. Sometimes one step will depend on the result of a previous step, sometimes not.

Any suggestions?

Answer 1

Your approach sounds reasonable to me (a combination of iterators/strategies).

Sometimes one step will depend on the result of a previous step, sometimes not.

This point can be interesting though. Since I don't know what each step is supposed to do in particular, I can give nothing but very general ideas.

The dependencies between all steps could be modeled through an interpreter-like syntax tree instead of sequential steps you take. Your StepRunner would therefore be discarded in favor of context/interpretation methods.

Another idea could be the use of monads, which allow you to sequentially glue steps together, but I don't know how easily this will integrate your existing object-oriented concept (since monads are usually used in functional programming).

Maybe you don't need to (over-)complicate things at all ;)

Answer 2

I am not sure I understood the question right, but since you are running steps in sequence, I will suppose that there is some contextual information being kept and thus you are talking about selecting the next step based on the result of the current one.

This is, in fact, what an automaton is about. You have various states linked together by transitions.

It is quite easy to ask each step to return some tag, perhaps merely a string or a suitably defined type.

Then, you define the automaton by determining a next step for each of the possible outputs of the current step.

For example, I actually use a framework (at work) that takes those transitions as a xml file... even though I quite dislike the fact that there is little check made on wether or not the transitions are correctly defined.

Note that in C++ it could be checked at compile-time (I am thinking on using Boost.Variant and a some metatemplate programming tricks).