Структуры данных LLD в контексте дизайна: почему некоторые проблемы требуют «лучшего» результата

Найти что-то быстро и быстро найти лучшее — это две совершенно разные инженерные проблемы. До сих пор в этой серии мы исследовали одно из наиболее распространенных поведений в программных системах: Быстрый поиск. Всякий раз, когда система уже знает, что она ищет - идентификатор пользователя, идентификатор продукта, идентификатор заказа или идентификатор сеанса - HashMap становится отличным выбором. Но не все программные проблемы работают таким образом. Представьте, что вы создаете приложение для совместного использования поездок. Всадник просит такси. Система еще не знает, какой драйвер назначить. Вместо этого он должен ответить на другой вопрос: «Из всех доступных водителей, кто лучший выбор?» Теперь рассмотрим планировщик задач. Сотни рабочих мест ждут своей очереди. Графикатор не спрашивает: «Найти работу No 123». Он спрашивает: «Какая работа должна быть следующей?» Представьте себе игровую платформу. Соревнуются тысячи игроков. Никто не спрашивает: «Найти ID 1057 игрока». Вместо этого пользователи спрашивают: «Кто входит в топ-10 игроков?» Эти проблемы принципиально отличаются от быстрого поиска. Речь не идет о поиске конкретного объекта. Они ищут лучший объект в соответствии с некоторыми приоритетами. Этот сдвиг в мышлении вводит еще одно важное дизайнерское поведение. Быстрый поиск против лучшего выбора Давайте сравним два разных требования. Требование 1 Система уже точно знает, что ей нужно. Задача состоит в том, чтобы эффективно ее решить. Требование 2 Система пока не знает ответа. Он должен сравнить несколько кандидатов, прежде чем принимать решение. Эти два поведения могут выглядеть одинаково. На самом деле они решают совершенно разные инженерные задачи. Каждая программная система не ищет одинаковым образом. Или: против или против. Первый вопрос всегда содержит идентификатор. Второй вопрос требует сравнения. Это различие меняет все. Понимание приоритета Представим себе отделение неотложной помощи. Прибыли пять пациентов. Если пациентов лечить просто в том порядке, в котором они прибыли, результат может выглядеть так. Технический