在前端项目里,设想有一个流程控制模块和一些负责单个组件、功能的子模块。流程控制引入子模块的实例,单方面调用:
流程控制:
import base
init(){
// 指示子模块初始化
base.init()
}
如果改为流程控制模块触发 init 事件,子模块里响应 init 事件:
流程控制:
// 只触发事件
init(){
fire('init')
}
子模块:
listen('init){
this.init()
}
修改之后看起来很好看,因为流程控制里不需要引用子模块,减少了一些 import。表面上看似乎是解耦了,但我觉得也有不妥的地方,似乎更难维护了:
- 这让子模块绑定了流程控制的逻辑。如果以后业务变更,增加了一个事件
event2
需要子模块再执行init
,需要同时修改这两个模块:流程控制触发事件,然后子模块里添加对这个事件的监听。但在一开始的形式里,只需要修改流程控制即可,后面的形式反而需要修改两个模块。 - 一开始的形式里,查看流程控制的代码时,可以清晰的看到工作流程,它指示各个子模块初始化。后面的形式里,看不到工作流程,只能去搜索有哪些子模块监听了它所触发的事件,相当麻烦。
到底该不该这样修改呢,或者是有更好的方式?但我在这方面造诣不深,想问下前辈们的意见,谢谢!
下面是个人的理解:
这种监听捕获处理流程没有太大的问题。
你所谓的增加事件
event2
,应该有对应的监听处理,而不应该简单的和init
关联啊,要么整合进init的处理过程,要么完全独立,这样来其实要么只修改子模块,要么因为是新事件,要同时修改子模块和主控(不过这样你前面的模式一样需要两个都修改)。关于你提到的2种模式对工作流程的关联特性其实是针对不同应用的,不能一概而论,有时第一种模式更适合,有时第二种模式适合,比如第二种模式主要是面对异步处理的,和第一种逻辑线路就不同的。