それぞれのデザインにはどのような考慮事項がありますか？イベントベースとポーリングコンポーネントの比較
デバイス（マウス、ゲームパッド、タッチなど）から入力を収集する入力コンポーネントを作成しているとします。
それが時間の所与の時点で所与の状態をテストする方法のAPIを提供することで設計の一つの方法は、別の方法は、いくつかの他の構成要素を有することである（このフレームに押され、このボタンは？である）
これらの要素をチェックし、起こっていることを通知するためにイベントを発生させます（例えば、APIユーザーによってフックされるイベントMouseClickedを定義するなど）。
なぜこれらのデザインをそれぞれ好むと思いますか？
消費コードに見られるように、「プッシュ」モデルと「プル」モデルの違いがあります。いずれかは、入力デバイスのコンテキストで動作します（あるレベルでは、デバイスがイベントによってトリガーとして使用されるようにOSによってポーリングされるか、単に次のポーリングまで有効な値を設定します）。私は、どちらかを使うかどうかは、重要なことに依存していると思います。それは今クリックされたのですか、それともクリックされましたか？この小さな意味の違いは、行動の大きな違いを意味する可能性があります。
あなたが探しているのは、チェックの時点でボタンが押されている場合、ポーリングメカニズムとして設定することです。あなたのライブラリ内のどのように知っているかのように頻繁に更新されるプロパティを提供し、ボタンが押されていることを確認するためにコンシューマーがチェックする。
ある時点でボタンが押されたことを伝える必要がある場合は、それをイベントとして設定します。このイベントは、この情報をリスナーに「プッシュ」します。
どちらを使用するかは、それを使用するプログラムの構造によって異なります。プログラムが最初から入力を待つように設計されたWindows GUIゲームは、イベントベースのモデルで最も効果的です。次のフレームを描くために入力の現在の状態を知る必要があるサイド・スクローラーのようなビデオ・ゲームは、ポーリング・メカニズムによってより効果的に機能する可能性があります。
まあまあ、このようなライブラリでは、両方のシナリオを並べて設定するのは簡単です。プロパティを更新し、誰かが聴いているなら、それを叫ぶ。そうすることで、コードを消費することは、ユーザが目的に必要と感じるようにプッシュまたはプルすることができます。
イベントが発生するたびにコンシューマがコールバックを指定して関連データを呼び出すことができるAPIを提供する方が良い場合があります。このようにして、コンポーネントのコンシューマはデータをポーリングしません。
私は現在、その一部を実際に並べて実装しています。唯一の問題は、コンポーネントが定期的にポーリングされていない限り、このコンポーネントからのイベントが発生しないことです。または、コンポーネント自体がポーリングを実行することを提案しましたか？ –
実際のハードウェアデバイスまたは抽象レイヤー（つまりDirectInput）のポーリングを実行し、次にコードを消費することでポーリングできるデバイス状態を示すプロパティーを設定してから、イベントを発生させるオブジェクトの状態への変更が発生します。したがって、マウスの状態を表す「Mouse」オブジェクトを作成していた場合、「LeftButtonDown」ブール値と「OnLeftButtonDown」というイベントが発生し、消費者はイベントに参加したり、満足しているプロパティをポーリングすることができます。 – KeithS
入力ストリームに依存するサイド・スクロール・ゲームをどのように修正しますか？長いボタン・プレスが同じ入力のストリームとして解釈され、レスポンスがアトミックではないため応答フィールが遅くなり、新しいキーが長いシーケンスは時間内に「検出」されていないようです... –