Полемика о времени жизни объекта

В своей предыдущей статье я представил алгоритм использования функции PulseEvent в качестве спускового крючка. Такой подход предполагает, что исполнительный поток создается во время старта программы и уничтожается только тогда, когда основная программа завершает свою работу. С таким подходом могут не все согласиться.

Я знаю людей, которые выступают против такого подхода. Их логика такова: предположим, пользователь запустил вашу программу и тут же закрыл её. В этом случае исполнительный поток создавался зря. Можно было бы обойтись и без него. Гораздо эффективнее было бы создавать поток, когда пользователь явно запустит обмен или обработку данных. Лично я считаю такое поведение пользователей маловероятным.
Чаще всего пользователи ведут себя так: запускают программу, делают какие-то настройки и запускают исполнительный поток (обмен с устройством, обработка файла с данными, что-то другое), по истечении какого-то времени останавливают поток, меняют настройки и перезапускают его. Такая процедура остановки, изменения настроек и перезапуска может повторяться несколько раз. В этом случае, чтобы минимизировать количество созданий/уничтожений потоков лучше создавать его один раз, а потом просто перезапускать его с измененными настройками.
Конечно поведение пользователей во многом зависит от типа вашей программы, какую задачу и как она должна решать. И все пользователи разные. Нельзя сказать, что все пользователи ведут себя абсолютно одинаково. Но и подстроить программу под каждого невозможно. Поэтому нужно ориентироваться на более вероятное поведение.
С другой стороны в вашей программе может быть реализовано несколько классов потоков, каждый из которых выполняет свою работу в зависимости от пожеланий пользователя. Заблаговременно создавать их все — слишком расточительно. Лучше создавать их по мере необходимости.
Также иногда, в силу архитектурных особенностей и реализации вашей программы, исполнительный поток проще пересоздать, чем перенастроить на новую работу.
Получается, что единственно правильного решения нет. В каждом есть свои положительные стороны. И выбирать тот или иной подход нужно исходя из конкретной решаемой задачи.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *