Моделювання ліфта за допомогою об'єктно-орієнтованого аналізу та дизайну [закрито]


134

Існує набір питань, які, як видається, часто використовуються в інтерв'ю та на заняттях, коли справа стосується об'єктно-орієнтованого проектування та аналізу. Це одна з них; на жаль, мій професор ООП у коледжі ніколи насправді не давав відповіді на це, і тому мені було цікаво.

Проблема полягає в наступному: розробити базовий набір об'єктів / методів, які будуть використані для імітації банку ліфтів. Які об’єкти та їх атрибути / методи?

На думку аргументів, припустимо, що наша будівля має двадцять поверхів; нижній поверх - вестибюль, а другий поверх підключається до гаража для паркування (отже, люди будуть входити / виходити з будівлі або на нижньому, або на другому поверсі). Є один банк ліфтів, який обслуговує всі поверхи; У банку ліфтів є три шахти ліфтів та по одному валу.

Який би був правильний спосіб моделювати це в об'єктно-орієнтованій моделі?


9
Це моє улюблене запитання про інтерв'ю. Попросити це просто, але напрочуд складно отримати правильно. Він включає такі речі, як черги, і їх можна легко розширити, щоб створити більше проблем. Наприклад, як би ви оптимізували алгоритм для скорочення часу очікування.
Роб Ді Марко

Так, це справді велике відкрите питання. На жаль, жодного разу не запитували цього :(
Урі

Відповіді:


165

Спочатку є клас ліфтів. Він має напрямок (вгору, вниз, стенд, обслуговування), поточний підлогу та список запитів поверху, відсортованих за напрямком. Він отримує запит від цього елеватора.

Тоді є банк. Він містить ліфти і отримує запити з поверхів. Вони заплановані на всіх діючих ліфтах (не в обслуговуванні).

Планування буде таким:

  • за наявності підберіть для цього поверху стоячий ліфт.
  • ще виберіть ліфт, що рухається на цей поверх.
  • ще виберіть стоячий ліфт на іншому поверсі.
  • ще виберіть ліфт з найменшим навантаженням.

Кожен ліфт має набір штатів.

  • Технічне обслуговування: ліфт не реагує на зовнішні сигнали (лише на власні сигнали).
  • Підставка: ліфт закріплений на підлозі. Якщо він отримає дзвінок. А ліфт на тому поверсі, двері відчинені. Якщо він знаходиться на іншому поверсі, він рухається в тому напрямку.
  • Вгору: ліфт рухається вгору. Кожен раз, коли він досягає підлоги, він перевіряє, чи потрібно йому зупинятися. Якщо так, він зупиняється і відкриває двері. Він чекає певний час і закриває двері (якщо хтось не рухається через них. Потім він видаляє підлогу зі списку запитів і перевіряє, чи є ще один запит. Якщо так, ліфт знову починає рухатися. Якщо ні, то він заходить державна трибуна.
  • Вниз: як вгору, але в зворотному напрямку.

Є додаткові сигнали:

  • тривога. Ліфт зупиняється. І якщо він знаходиться на підлозі, двері відчиняються, список запитів очищається, запити переносяться назад до банку.
  • двері відчинені. Відчиняє двері, якщо ліфт знаходиться на підлозі і не рухається.
  • двері закриваються. Закрийте двері, якщо вони відкриті.

EDIT: Деякі ліфти не запускаються в нижній / першій частині поверху. у разі хмарочосів.

min_floor & max_floor - два додаткові атрибути для Elevator.



1
Схоже, цей підхід до планування не потребує певних оптимізацій, наприклад, якщо ліфт вже йде на поверх, де людина звернулася з проханням про ліфт, тоді не потрібно планувати прибуття іншого елеватора.
Лірон Ягдав

Чи будуть запит на отримання та планування синхронним чи асинхронним? Якщо async, то як би ми цього домоглися?
Rohitashwa Nigam

18

У книзі Дональда Кнута «Мистецтво комп’ютерного програмування» Vol.1 демонструється ліфт та структури даних. Кнут представляє дуже ретельну дискусію та програму.

Кнут (1997) "Інформаційні структури", Мистецтво комп'ютерного програмування Vol. 1 стор.302-308


9
пов’язані з книгами Google вище.
виноградна лоза

2
У цьому розділі книги (докладно) описано, як запускати ліфтове моделювання. Він НЕ описує, як його моделювати (способом OOP). Але так ... велика книга!
користувач7,

17

Я бачив багато варіантів цієї проблеми. Однією з головних відмінностей (що визначає складність) є те, чи існує якась централізована спроба створити "розумну та ефективну систему", яка б мала балансувати навантаження (наприклад, відправляти більше літніх холостих ліфтів у лобіювання вранці). Якщо це так, дизайн буде включати цілу підсистему з дійсно веселим дизайном.

Повноцінний дизайн, очевидно, занадто багато, щоб представити тут, і є багато альтернативних. Ширина також не зрозуміла. В інтерв'ю вони спробують розібратися, як би ви думали. Однак це вам потрібно:

  1. Представлення центрального контролера (якщо він існує).

  2. Представлення ліфтів

  3. Представлення інтерфейсних блоків ліфта (вони можуть відрізнятися від елеватора до ліфта). Очевидно також дзвоніть кнопки на кожному поверсі тощо.

  4. Зображення стрілок або індикаторів на кожному поверсі (майже «вид» моделі ліфта).

  5. Представництво людини та вантажу (може бути важливим для факторингу максимальних навантажень)

  6. Представлення будівлі (в деяких випадках, оскільки певні поверхи можуть бути заблоковані часом тощо)




2

Що потрібно враховувати під час проектування системи ліфтів,

Elevator
Floor/Location Identifier
Number of steps
Rotation speed
Daterange
InstallationDate
MaintainenceDate
Department Identifier
AllowedWeight
Detail / Description
Poison Ratio (Statistics)
Start
Stop
SetDirection
SetRotationSpeed
EmergencyStop = Stop + Alert
EmergencyAccidentSenser Handler

Кожне натискання кнопки призводить до запиту ліфта, який потрібно подати. Кожен із цих запитів відстежується у глобальному місці

Кількість ліфтів у будівлі визначатиме користувач. Будівля міститиме фіксовану кількість поверхів. Кількість пасажирів, які можуть поміститися в ліфт, буде визначена. Пасажири будуть рахуватися під час виходу з ліфта на місце призначення. Місце призначення визначатиметься за допомогою "випадкового" інтервалу Пуассона. Коли всі пасажири в ліфті дістаються місця призначення, ліфт повернеться у вестибюль, щоб забрати більше пасажирів


2

Головне хвилюватися - це як ви сповістить ліфт, що йому потрібно рухатися вгору або вниз. а також, якщо ви будете мати централізований клас, щоб контролювати цю поведінку, і як ви могли розподілити контроль.

Здається, це може бути дуже просто або дуже складно. Якщо ми не заберемо одночасність або час, коли ліфт дістанеться до одного місця, тоді здається, що це буде просто, оскільки нам просто потрібно перевірити стан ліфтів, як це рухається вгору або вниз, чи стоїть нерухомо. Але якщо ми змусимо Elevator реалізувати Runnable, і постійно перевіряти та синхронізувати чергу (linkedList). Клас контролера призначить, який поверх перейти в чергу. Коли черга порожня, метод run () буде чекати (queue.wait ()), коли підлозі буде призначений цей елеватор, він викличе queue.notify (), щоб прокинути метод run () та запустити ( ) метод викличе goToFloor (queue.pop ()). Це ускладнить проблему. Я намагався написати це на папері, але не думаю, що це працює. Схоже, нам тут не потрібно брати до уваги паралельність чи терміни,

Будь-яка пропозиція?

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.