Question

我发现自己不时会做这种事情，我想知道这是设计上的问题还是有更好的设计模式可以使用。

有一个具有许多步骤的过程，在编译时已知，但可能在将来发生变化。我在一个抽象的步骤类中捕获共性，编写一个StepLister返回一系列步骤，每个步骤继承自步骤类，然后编写一个StepsRunner调用StepLister，然后迭代列表并运行每个步骤。有时一个步骤会依赖于前一个步骤的结果，有时则不会。

有什么建议吗？

Answer 1

你的方法听起来对我来说很合理（迭代器/策略的组合）。

有时候，一个步骤会依赖于前一步骤的结果，有时则不需要。

这个点可能会很有趣。因为我不知道每个步骤具体要做什么，所以我只能提出非常一般性的想法。

所有步骤之间的依赖关系可以通过类似解释器的语法树来建模，而不是采取顺序步骤。因此，您将放弃您的StepRunner，转而采用上下文/解释方法。

另一个想法可能是使用单子，它允许您将步骤顺序粘合在一起，但我不知道它如何轻松地将其与现有的面向对象的概念集成在一起（因为单子通常用于函数式编程）。

也许你根本不需要（过度）复杂化问题 ;)

Answer 2

我不确定我正确理解了问题，但是由于你正在按顺序运行步骤，我会假设有一些上下文信息被保留，因此你是根据当前步骤的结果选择下一步。

事实上，这就是自动机的本质。您有通过转换相互链接的各种状态。

很容易要求每个步骤返回一些tag，也许仅仅是一个字符串或一个定义合适的类型。

然后，您通过确定当前步骤的每个可能输出的下一步来定义自动机。

例如，我实际上在工作中使用一个框架，它以xml文件形式处理这些转换......尽管我相当不喜欢这个事实，即几乎没有检查是否正确定义了这些转换。

请注意，在C++中它可以在编译时进行检查（我正在考虑使用Boost.Variant和一些元模板编程技巧）。