Основанные на событиях против компонентов опроса - PullRequest
1 голос
/ 27 июня 2011

Каковы предпочтения для каждого дизайна?

Предположим, я пишу компонент ввода, который собирает входные данные от устройств (мыши, геймпада, сенсорного экрана и т. Д.).

Один из способов проектированиябыло бы предоставить API методов, которые тестируют данное состояние в данный момент времени (нажата ли эта кнопка в этом кадре?)

Другой способ - заставить какой-либо другой компонент непрерывно вызывать этот компонент каждый кадр, проверяя эти вещи, вызывая события для уведомления о происходящих событиях (например, определяя событие MouseClicked, которое будет перехвачено пользователем API).

Почему вы предпочитаете каждый из этих проектов?

Ответы [ 2 ]

7 голосов
/ 27 июня 2011

Разница между моделью "push" и моделью "pull", что видно по потреблению кода.Либо работает в контексте устройства ввода (на каком-то уровне ОС опрашивает устройство для использования в качестве триггера для события или просто для установки значения, действительного до следующего опроса).Я думаю, что решение использовать один или другой зависит от того, что является значительным;это щелкнуло сейчас, или это щелкнуло?Это небольшое семантическое различие может означать существенные различия в поведении.

Если вы ищете, что кнопка нажата с момента проверки, то установите ее в качестве механизма опроса.Предоставьте свойство, которое обновляется так часто, как вы знаете, как из вашей библиотеки, что потребители будут проверять, чтобы определить, нажата ли кнопка.

Если вам нужно передать, что кнопка была нажата в какой-то моментвремя, затем установите его как событие, которое будет «передавать» эту информацию своим слушателям.

То, что вы хотите использовать, зависит от того, как вы структурируете программу, которая ее использует.Игра с графическим интерфейсом Windows, в которой программа разработана с нуля, чтобы просто ждать ввода, лучше всего подходит для модели, основанной на событиях.Видеоигра, такая как боковой скроллер, где вы должны знать текущее состояние входов, чтобы нарисовать следующий кадр, может лучше обслуживаться механизмом опроса.

Откровенно говоря, в такой библиотеке, как этабыло бы тривиально настроить оба сценария бок о бок;обновить свойство, а затем, если кто-то слушает, выкрикивать его.Таким образом, потребляющий код может толкать или тянуть, так как пользователь считает необходимым для этой цели.

0 голосов
/ 27 июня 2011

Может быть, лучше предоставить API, в котором потребитель мог бы указать обратный вызов, который мог бы вызываться с соответствующими данными всякий раз, когда происходит событие.Таким образом, потребитель вашего компонента не будет опрашивать данные.

...