1
Nosub 128 天前 via iPhone
模板方法。
|
2
root71370 128 天前
责任链
|
3
wjx0912 128 天前
装饰器模式?
|
4
ovtfkw 128 天前
流水账模式
|
5
31415926535x 128 天前
1 、step2,4 短期内如果不会膨胀很多不同的逻辑,就直接一串写下去,
2 、如果现阶段已经较多,抽象类中控制主流程,变化的内容交给子类实现,工厂+模板 3 、如果一定后续会增多,责任链或者流程引擎编排下子任务 ( step1, 4 是什么内容呢,我猜是数据加载和收尾发消息等等操作,如果是的话,可以搞个 init, process, after 的模板,process 走工厂 |
6
1008610001 128 天前
模板,或者你把 2 和 4 抽一个接口,由调用方传进来实现调用也可以
|
7
sagaxu 128 天前
最简单的方式,不用什么模式
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(...): Base { //根据场景实例化相应的子类 } |
8
zgl263885 128 天前 via iPhone
命令模式?把每个步骤封装成一个个的命令,让后组合一个命令数组,由执行器去控制步骤的逐步执行以及暂停恢复等过程。另外可能会需要状态机模式来实现步骤执行的状态切换管理。
|
9
ixixi 128 天前 1
按我的理解是 rxjs
|
10
mitoop 128 天前 via iPhone 2
初步来看,模板模式 加 策略模式 ,模板实现不同场景,策略决定使用哪个场景。
|
11
z1829909 128 天前
我觉得不用模式, 先做到代码复用, 等这些步骤多到维护很麻烦再设计怎么抽象.
设计模式本身就会增加理解成本. 当维护成本 >> 理解成本的时候才是划算的. |
12
RainCats 128 天前
我可能是用责任链串起来,然后 2 和 4 用策略模式+函数式
|
13
dododada 128 天前
说来惭愧,从来没有认真的研究过设计模式
|
14
yule111222 128 天前
不需要任何设计模式
|
15
laminux29 128 天前
如果业务复杂,建议用基于数据库的流程引擎来开发,因为方便多人协作开发+方便调试排错。
举个简单例子,APP 跑到某一步,突然崩了,此时完整的数据过程,都在数据库,你完全可以慢慢检查,最后用数据库,直接恢复现场。 |
16
HaibaraDP 128 天前
pipeline
|
17
xuanbg 128 天前
不需要什么设计模式。教你一个万能的应对方案,就是封装。以 OP 的实际需求为例,可以把每个步骤分别封装。譬如第二步会根据不同的类型采取不同的处理方式,那就在这一步的内部,根据数据类型来进行不同的分支流程。这样,变化就被限制在内部,从而不影响其他组件。
|
18
SuperDaFu 128 天前
责任链构建流程,每一个流程可以上命令/模板/策略维护自己的组件。
可以用消息来驱动整个流程运转 |
20
ilucio 127 天前
这就是工作流系统的典型实现,最近刚写过一个,用了责任链+策略模式,把责任链换成模板模式也可以,看具体需求了。我觉得这个需求里最难的是每个 step 的
|
21
ilucio 127 天前
我觉得最难的是每个 step 的可忽略、可重试、可跳过设计实现。。
|
22
monkeydream 127 天前
不能为了设计模式而模式,一开始还是建议先封装+组合。
|