Управляемый событиями по сравнению с [закрытым] последовательным программированием
для изучения, что используют библиотеки двоичный файл используйте ldd
ldd path/to/the/tool
, который необходимо было бы записать небольшому сценарию оболочки для получения до разбивки в масштабе всей системы.
2 ответа
Два разных метода для поддержки двух разных потребностей. Если у вас есть проблема, связанная с событиями, вам следует использовать методологию, управляемую событиями. Если вам нужно выполнить процедуры с определенными данными, но вы не беспокоитесь о том, что происходит где-то еще, тогда, очевидно, вы хотите использовать более «последовательный» стиль.
Обратите внимание, что обычно эти две вещи сочетаются. Запуск, завершение работы программы и, возможно, основной цикл обработки (скажем, процессор фильтров в приложении изображения) будут в основном последовательными, в то время как его уровень пользовательского интерфейса и взаимодействие компонентов будут управляться событиями.
Насколько я понимаю:
Дизайн, управляемый событиями, хорош для программного обеспечения, которое должно реагировать на запросы / требования пользователей. Насколько я могу судить, как правило, большинство программ с графическим интерфейсом и онлайн-программ таковы. Он не имеет или почти не имеет предопределенного порядка операций, поскольку пользователь может делать что угодно (в рамках приложения).
Последовательный чаще встречается при пакетной обработке. Программное обеспечение, которое работает практически без участия пользователя. Порядок операций в значительной степени предустановлен.
Здесь нет строгого разделения, поскольку инструменты на основе графического интерфейса, очевидно, могут включать относительно длительные пакетные процессы.