Я играю с дизайном Lift Simulation. У меня есть Контроллер Лифтов с коллекцией Лифтов. Лифт движется через определенные состояния (например, STATIONARY, MOVING, DOORS_OPEN и т. Д.). - В состоянии MOVING процесс Lift будет просто спать в течение X мс. В настоящее время я концентрируюсь на взаимодействиях между процессом Lift Controller и коллекцией процессов Lift.
По сути, Контроллер лифтов должен координировать лифты и поэтому должен принимать запросы этажей и определять, какой лифт лучше всего обслуживать этот запрос, а затем впоследствии информировать этот лифт.
Мои первоначальные мысли состояли в том, чтобы каждый Лифт после получения запроса этажа перемещался через различные состояния и затем информировал Контроллера Лифта, когда он завершит перемещение на конкретный этаж. Однако при такой конструкции контроллер лифта может запросить лифт, чтобы увидеть, какой этаж находится рядом с ним, принять решение для этого лифта (т.е. остановиться на следующем этаже), но к тому времени, когда он сказал лифту остановиться, этот лифт перешел мимо этого этажа (задержка, скажем, из-за перехвата сети).
Чтобы избежать подобных проблем (когда Lift Controller принимает решения на основе устаревшей информации), я подумал о том, чтобы сделать Lift Controller ответственным за перемещение каждого Lift через его состояния. В этой модели контроллер лифта знает, в каком состоянии находится лифт, говорит ему сделать переход, а затем знает, в каком состоянии он будет после. Таким образом, контроллер лифта всегда имеет актуальную информацию о том, что делают лифты, и его действия никогда не будут не синхронизированы с отдельными состояниями лифта.
Есть ли у людей какие-либо проблемы с этим типом подхода (в отношении многопоточности, масштабируемости) - есть ли лучшие способы моделирования этого? Мысли приветствуются!