採点アプリと解説アプリのアーキテクチャ
アプリについて：これはAndroidアプリです。アプリには2つのコンポーネント/ 2人の異なるユーザーがいます。ゲームをスコアリングするスコアラーと、ゲームの解説を表示するファンです。
- 得点ユーザー：得点者はライブ野球の試合を観戦し、試合の各ピッチ/イベントの後にスコアを記録します。これらのイベントはサーバーにプッシュされ、スコアラーの電話にローカルに保存されます。
- ファンユーザー：ゲームをフォローしたいファンは、スコアリングアプリから送信されたイベントに基づいて、サーバーから送信されたファンアプリで、ゲームの実況/ピッチごとの解説を表示できます。
各ゲームには、ゲームに関連付けられたデータのセットがあります。 -などのゲーム全体を通じて変化しない固定データ：
- チーム名
- 選手一覧
- 根拠名..ETC
各試合には、イベントのリスト/配列も含まれます。各イベントには多くの情報が含まれます。
- ねり粉名
- 投手名
- 得点されたラン
- 改札が取られた場合、改札はどのように取られましたか。 .. ETC
各ゲームで生成されたこれらのイベントのリストは、サーバーに保存されます。一定期間にわたって、これらの試合ごとのイベントは投手に関する興味深い洞察を生み出します。例：ピッチャーは左打者に対してどのように優れているか、打者はチームが勝ったときにどのように平均が優れているかなど。
必要な問題/提案：
- スコアラーがイベントのスコアを間違えた可能性があり、最後のイベントを元に戻す必要があります。これをサポートするためにAndroidで使用するデザインパターンはどれですか？
- イベントをAndroidアプリにJSONまたはPOJOとして保存する必要がありますか？スコアリングアプリの各イベントの後、イベントをローカルデータベースとサーバーに保存する必要があります。データはサーバーはJSONであり、mongoDbにダンプされます。
- アプリは、解説アプリに表示するために各イベントの詳細を保存する必要があります。また、洞察を生成する必要もあります。スコアラーUIには、現在の打者、現在の打者によって得点されたラン、合計、現在のピッチャー情報なども表示されます。これは、イベントごとに変化し続けます。これらのデータはすべて、UIで次の2つの方法で取得および更新できます。
- イベントリストは新しいイベントの後に更新され、他のすべての派生データはイベントをループすることによって再度計算されます。したがって、UNDOの場合、最後のイベントが削除され、再度ループすると実際の値が再計算されます。これにより、データを正確に保つことができ、エラーが発生しにくくなりますが、毎回長いリストを走査する必要があります。
- イベントリストとともに、UIに表示される他の情報の値を保持する別のデータ構造があります。イベントリストは、新しいイベントの後に更新され、他のすべての派生データも他のデータ構造で更新されます。これにより、データの不一致が発生し、データが複製される可能性がありますが、イベントの長いリストを毎回トラバースする必要はありません。
私はデザインパターンにしばらく時間を費やしましたが、何を進めるかを決めることができませんでした。専門家の意見/指示または同様の行で何かをした人からの言葉は非常に役に立ちます。
アーキテクチャは、パターンの山ではありません。それは、絵画の発展を隅々まで回避する、まとまりのある方法で従う一連の原則です。宗教的な熱意はここではあなたの友達ではありません。誤用を実用的に回避することです。
コマンドパターン を思い起こさせるundoについて言及しています。これにこだわるのは、ユーザーが使用できるすべてのコマンドであり、コマンドが実行したことをすべて元に戻す元に戻すコードも必要です。
ただし、元に戻すときに状態を最初から再計算する用意があることにも言及します。つまり、 不変 ルートに進むことができます。イベントを変更するのではなく、元に戻されていないすべてのイベントから状態を再計算するだけです。ここでの摩擦はパフォーマンスです。元に戻すと心的外傷になる可能性があります。ただし、これは、前の状態を保存してイベントの短いリストを再生することで軽減できます。状態を保存する頻度は、 時空のトレードオフ パフォーマンスを調整するために使用するチューニング変数です。