リストではなく、キューまたはキューのような構成を使用してレストランをモデル化し、別のアプローチを採用することをお勧めします。このように、到着した順に人を保存するので、並べ替えは必要ありません。
人々をPartyオブジェクトにグループ化します。締約国が到着したら、それらをキューに追加できます。次に、キューを確認し、パーティに予約がある場合は、それらをキューから削除して、テーブルに送信します。パーティーに予約がない場合は、そのサイズのパーティーでテーブルが利用可能かどうかを確認し、利用可能な場合は、そのパーティーをキューから削除します。
それ以外の場合は、テーブルが使用可能になるまで待つことができます。そのイベントが発生すると、テーブルのサイズに合うパーティーを探して、再びキューを歩くことができます。また、この時点でキューに予約のあるパーティーが含まれているかどうかを確認することもできます。つまり、優先されます。これを使用Queue.First(x => x.HasReservation && x.Size <= Table.Places)
して、予約があり、テーブルに収まる最初のセットの人々をキューから取得します**。それ以外の場合はQueue.First(x => x.Size <= Table.Places)
、テーブルに収まる最初のキューのセットを取得します。
キューを使用する利点は、並べ替えが不要なことです。人のパーティを到着順に処理し、予約のある人を優先します。
2つのポイントでキューをチェックします。
- 到着時(予約はありますか、テーブルはありますか)
- テーブルが利用可能になったら、最初に予約をしてテーブルに収まるようになっている人を探します。一致するものがない場合は、テーブルサイズに一致する(またはテーブルに収まる)キューから最初の人のセットを取得します
それは始めるのに良い場所です。
アップデート
ご存知のように、キューの途中からアイテムを削除することはできません。これは、キューが先入れ先出し(FIFO)であるためです[後入れ先出しのスタックとは対照的に-LIFO]。ソートを回避するために、セマンティクスのようなキュー付きリストを使用できます。この回答には良い例があります。
**ここにはもう1つの興味深いキューイングの問題があります。それは、効率の問題です。4か所のテーブルができたらどうしますか?テーブルに収まる最初に到着したパーティに渡すか、テーブルに収まるキュー内の最大のパーティに渡します。明らかに、最初のオプションは最も長く待っている人を座っているのでカスタマーサービスに最適ですが、2番目のオプションはテーブルをより十分に活用しているので利益を最大化します:-)