基于事件和轮询组件

Question

有利于每项设计的考虑因素是什么？

假设我正在编写一个从设备收集输入的输入组件（鼠标，游戏手柄，触摸等）。

设计它的一种方法是提供一个方法的API，在给定的时间点测试一个给定的状态（在这个框架中按下这个按钮？）

另一种方法是让其他组件每帧连续调用此组件，检查这些内容，引发事件以通知正在发生的事情（例如 - 定义将被API用户钩住的事件MouseClicked）。

为什么你喜欢这些设计？

Answer 1

区别在于“推”模型和“拉”模型，如消费代码所示。要么在输入设备的上下文中工作（在某种程度上，设备由OS轮询以用作事件的触发器，或者仅设置在下次轮询之前有效的值）。我认为使用其中一个的决定取决于重要的事情;它现在点击了，还是点击了？这种轻微的语义差异可能意味着行为的主要差异。

如果您要查找的是在检查时按下按钮，则将其设置为轮询机制。提供一个经常更新的属性，如您所知，从库中​​，消费者将检查以确定按下按钮。

如果您需要传达某个时间按下按钮，请将其设置为事件，这会将此信息“推送”给听众。

您要使用哪一个取决于您如何构建使用它的程序。一个Windows GUI游戏，其中程序是从头开始设计的，只是等待输入，最好由基于事件的模型提供。视频游戏，如侧卷轴，您必须知道输入的当前状态才能绘制下一帧，轮询机制可能会更好地服务。

坦率地说，在像这样的图书馆中，将这两种情景并排设置是微不足道的;更新一个属性，然后如果有人在听，请喊出来。这样消费代码可以推送或拉动，因为用户觉得他们的目的是必要的。

Answer 2

提供API可能会更好，消费者可以指定一个回调，可以在事件发生时使用相关数据调用该回调。这样，组件的使用者就不会轮询数据。