请教一下，这种情况用哪个设计模式比较好呢

模板方法。

责任链

装饰器模式？

流水账模式

1 、step2,4 短期内如果不会膨胀很多不同的逻辑，就直接一串写下去，
2 、如果现阶段已经较多，抽象类中控制主流程，变化的内容交给子类实现，工厂+模板
3 、如果一定后续会增多，责任链或者流程引擎编排下子任务

（ step1, 4 是什么内容呢，我猜是数据加载和收尾发消息等等操作，如果是的话，可以搞个 init, process, after 的模板，process 走工厂

模板，或者你把 2 和 4 抽一个接口，由调用方传进来实现调用也可以

最简单的方式，不用什么模式

class Base {
func step1()
func step2()
func step3()
func step4()

func process() {
step1()
step2()
step3()
step4()
}
}

class Foo {
override func step1()
override func step4()
}

class Bar {
override func step1()
override func step4()
}

func create(...): Bae {
//根据场景实例化相应的子类
}

命令模式？把每个步骤封装成一个个的命令，让后组合一个命令数组，由执行器去控制步骤的逐步执行以及暂停恢复等过程。另外可能会需要状态机模式来实现步骤执行的状态切换管理。

按我的理解是 rxjs

初步来看，模板模式 加 策略模式 ，模板实现不同场景，策略决定使用哪个场景。

我觉得不用模式, 先做到代码复用, 等这些步骤多到维护很麻烦再设计怎么抽象.
设计模式本身就会增加理解成本. 当维护成本 >> 理解成本的时候才是划算的.

我可能是用责任链串起来，然后 2 和 4 用策略模式+函数式

说来惭愧，从来没有认真的研究过设计模式

不需要任何设计模式

如果业务复杂，建议用基于数据库的流程引擎来开发，因为方便多人协作开发+方便调试排错。

举个简单例子，APP 跑到某一步，突然崩了，此时完整的数据过程，都在数据库，你完全可以慢慢检查，最后用数据库，直接恢复现场。

pipeline

不需要什么设计模式。教你一个万能的应对方案，就是封装。以 OP 的实际需求为例，可以把每个步骤分别封装。譬如第二步会根据不同的类型采取不同的处理方式，那就在这一步的内部，根据数据类型来进行不同的分支流程。这样，变化就被限制在内部，从而不影响其他组件。

责任链构建流程，每一个流程可以上命令/模板/策略维护自己的组件。
可以用消息来驱动整个流程运转

@laminux29 这个东西有没有例子可以看看

这就是工作流系统的典型实现，最近刚写过一个，用了责任链+策略模式，把责任链换成模板模式也可以，看具体需求了。我觉得这个需求里最难的是每个 step 的

我觉得最难的是每个 step 的可忽略、可重试、可跳过设计实现。。

不能为了设计模式而模式，一开始还是建议先封装+组合。