基于事件与轮询组件
本文关键字:组件 事件 于事件 | 更新日期: 2023-09-27 18:00:27
有利于每种设计的考虑因素是什么?
假设我正在编写一个从设备(鼠标、游戏板、触摸屏等)收集输入的输入组件。
设计它的一种方法是提供一个API方法,在给定的时间点测试给定的状态(这个按钮在这个框架中按下了吗?)
另一种方法是让其他组件在每帧持续调用该组件,检查这些事情,引发事件以通知正在发生的事情(例如,定义一个将被API用户钩住的事件MouseClickd)。
你为什么喜欢这些设计?
正如消费代码所示,"推"模型和"拉"模型之间的区别。要么在输入设备的上下文中工作(在某种程度上,操作系统轮询设备以用作事件的触发器,要么只是设置一个有效值,直到下一次轮询)。我认为使用其中一个或另一个的决定取决于什么是重要的;它是现在被点击了,还是已经被点击了?这种微小的语义差异可能意味着行为上的重大差异。
如果你想要的是在检查时按下了一个按钮,那么将其设置为轮询机制。提供一个在库中随时更新的属性,消费者将检查该属性以确定是否按下了按钮。
如果您需要传达某个按钮在某个时间被按下,那么将其设置为一个事件,该事件将向侦听器"推送"此信息。
你想使用哪一个取决于你如何构建使用它的程序。Windows GUI游戏中,程序从头开始设计,只是为了等待输入,最好使用基于事件的模型。视频游戏,比如侧滚动器,你必须知道输入的当前状态才能绘制下一帧,最好有一个轮询机制。
坦率地说,在这样的库中,并排设置这两种场景是微不足道的;更新一个属性,然后如果有人在听,就大声喊出来。通过这种方式,用户可以根据自己的需要推送或拉取代码。
最好提供一个API,消费者可以在其中指定一个回调,每当事件发生时,可以使用相关数据调用该回调。这样,组件的使用者就不会轮询数据。