大话设计模式——关注点分离原则下的事件处理

事件的关注点在哪里

事件的关注点在哪里？是事件派发者，事件监听者，还是事件本身？

为什么事件派发者不是关注点

举个例子------使用事件委托对按钮点击事件进行监听：

ini 复制代码

document.addEventListener('click',(e)=>{
    if(e.target.id==='search'){}
    if(e.target.id==='reset'){}
})

请问这段代码中关注点是按钮(派发者) 还是 **click(事件)**本身？

很多人会陷入一个误区，认为关注点是按钮。但这段代码里之所以要判断按钮，是为了区分事件。

如果我们能够派发自定义事件，比如dispatchEvent(SearchEvent)，那么按钮在这个事件逻辑中就并不重要了。

为什么事件订阅者不是关注点

组件内监听dom操作是前端开发中最普遍的事件处理场景：

javascript 复制代码

function SearchBtn(){
    const search = ()=> {
           search...
    }
    return <Button onClick={search}>search</Button>
}

请问这里的关注点是需要监听按钮点击事件的SearchBtn组件还是search本身呢？

可能很多人认为这里的关注点是SearchBtn，但其实SearchBtn最核心的内容是search本身，search方法放入任意一个组件内，都能使它成为SearchBtn。

为什么要从事件本身出发

对于简单的业务，事件处理程序放入任意地方都可以，然而对于复杂项目，尤其是有大量基于事件驱动的逻辑的项目，从事件本身出发能减少大量的隐形bug。

比如有一个折线图，里面可能有多条数据，当滚轮缩放后，需要依据当前范围重新采样数据并渲染，数据本身又会被某个设置进行n倍缩放，曲线重新渲染后，相关标注跟随刷新。。。

如果我们关注于事件本身，那么可能会有如下代码：

go 复制代码

chart.on('dataZoom',(range)=>{
     //根据范围精确采样曲线数据后重新渲染
    //dataModule.handle(range)
    //曲线根据范围和自身配置进行二次数据处理
    lineModule.handleData(range)
    //自定义标注位置/数据更新
    markerModule.update(range)
    //折线图相关配置记录和更新
    chartModule.update(range)

})

如果我们关注于事件订阅者，可能有如下代码

kotlin 复制代码

class DataModule{
    init(){
        chart.on('dataZoom',this.handle)
    }
}

class LineModule{
    init(){
        chart.on('dataZoom',this.handleData)
    }
}
class MarkerModule{
    init(){
        chart.on('dataZoom',this.update)
    }
}
...

显然，前一种写法事件处理更紧凑，而后者可能会有以下问题：

事件冲突和依赖关联

难以协调各逻辑的优先/权重/排他/冲突/依赖等问题。并且一旦有处理顺序关联，很容易因对象的创建先后时机造成事件处理的bug。

模块耦合

理论上各模块应专注于自身业务，而不应过多关注外部环境。事件处理其实是跨模块的逻辑编排，如果将事件放入业务模块中，各模块将紧密耦合在一起，牵一发而动全身，不仅难以复用和扩展，也很难进行测试。