基于事件和轮询组件

Question

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

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

设计这将是提供的，在给定的时间点测试给定状态的方法的API的一种方式（是该按钮在该帧中按下了吗？）

另一种方式是有一些其它部件不断调用这个组件每一帧，检查这些事情，引发事件通知发生的事情（例如 - 定义一个事件MouseClicked，将被API用户挂钩）。

为什么你会喜欢这些设计？

Answer 1

区别在于“推”模型和“拉”模型之间，如消费代码所见。可以在输入设备的上下文中工作（在某个级别，设备由操作系统进行轮询以用作事件的触发器，或者仅设置一个有效的值直到下一次轮询）。我认为使用这个或那个的决定取决于什么是重要的;它现在点击了还是被点击了？这种较小的语义差异可能意味着行为的重大差异。

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

如果您需要传达一个按钮在某个时间被按下，然后将其设置为一个事件，它将“推送”这个信息给它的听众。

你想使用哪一个取决于你如何构造使用它的程序。一个Windows GUI游戏，其中程序设计从简单地等待输入，最好由基于事件的模型提供服务。一个视频游戏，像一个侧滚屏，你必须知道输入的当前状态以绘制下一帧，这可能更好地由轮询机制提供。

坦率地说，在像这样的库中，并行设置两种方案都是微不足道的;更新一个属性，然后如果有人在听，大声说出来。这种消费代码可能会随着用户对于他们的目的感到需要而推动或拉动。

Answer 2

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