Только спустя много лет и проектов появилась идея, как нормальнее делать логику взаимосвязей значений для больших списков Use Cases, для фреймворков, где нет похожего. Долой дергающие друг друга мелкие обработчики OnChange контролов, сбинженых с пропертями business entity. Они, вместе с прочими мелкими методами, поналепленными для code reuse, приводят к непоняткам:
- не прослеживаются связи с конкретными Use Cases из спецификации
- maintainability отстой - давно думаю, что длинный метод и портянка на 1-2 экрана плотного кода, хоть на Domain Specific Language, лучше, чем куча коротких методов, длинные стеки вызовов и необходимость слегка повышенных способностей, чтобы охватить код в достаточном объёме.
OnChange обработчик может быть 1 для всех контролов, и это вполне может быть единственный метод, содержащий всю калькуляционную или валидирующую логику entity. В цикле с ограниченно разумным числом повторений и бросанием ошибки при превышении, что позволит что-то поменять. Флаг(и) для отключения повторного вхождения через OnChange, равно как и рестарт вычислений как через OnChange, так и через break - этого может быть достаточно для всех случаев. Чем-то напоминает Angular(JS) с его рекалькуляцией пропертей модели?..
Всё, что относится к бизнес-логике, должно быть плотно собрано в 1 место, и Use Cases должны чётко прослеживаться. Как это будет уживаться с вспомогательными операциями типа загрузки дочерних данных по OnChange какого-нибудь ChildObjectId navigation property, дело другое. Тут уже можно мелкие методы подергать из портянки. А рассовывание той же установки Enabled по разным методам - как сверять с Use Cases будем? Тесты писать?..
Вышесказанное относится, скорее, к десктопным проектам, к тем же .NET WinForms. И так же относится к каким-нибудь MVP Presenter or any business logic class, куда вы вынесете логику из "View" (UI). Даешь сосредоточение логики в портянке на 1-2 экранах плотного кода. Долой мелкие методы
