Цитата:
Сообщение от
S.Kuskov
А я бы делал такое деление за счёт распределения соответствующих методов по разным классам. Отдельный класс, который отвечает за бизнес-логику, и отдельный класс который отвечает за взаимодействие с пользователем, который в случае чего дёргает методы первого класса.
Хорошее замечание, спасибо. Тут все очень сильно зависит от задачи, поэтому мнений может быть много и разных.
Я в качестве примера приводил операцию разноски, которая заведомо предполагает выполнение большого количества проверок перед выполнением алгоритма. В этом примере класс, отвечающий за взаимодействие с пользователем будет минимален, потому что как такового взаимодействия нет (кнопку нажали и процесс пошел).
Если в качестве примера приводить допустим операцию закрытия склада / расчета сводного плана, то да, действительно до запуска процедуры может быть куча параметров в диалоге и действительно будет актуальной задача по обработке взаимодействия с пользователем.
Но в целом - я также считаю, что логику взаимодействия с пользователем нужно отделять от внутренней логики, чтобы была возможность программно запустить обработку внутренней логики отбросив логику взаимодействия с пользователем (условно - программно передать процедуре закрытия склада все необходимые параметры и программно ее запустить, не связываясь с обработчиком параметров в диалоге)