Доброго дня!
Натолкнулся случайно на здесь

Автор(ы): Александр Бабаев
Дата: 12.05.2006
Метод, представленный в статье, кардинально отличается от тех методов, которые применяются сейчас для создания логики пользовательского интерфейса. Он позволяет, в конечном счете, улучшить качество конечного интерфейса и его исходного кода, ускорить разработку и упростить поддержку. Метод основывается на подходе, активно пропагандируемом Анатолием Абрамовичем Шалыто и использует большую часть достоинств автоматного метода программирования.

статью, оценил оригинальность идеи, а потом попытался притянуть ее к реальной ситуации и кое-чего не понял.
Как быть если следующее состояние автомата не может быть однозначно определено парой: (<текущее_состоянием>, <выполняемое_действие>), а завит также от других факторов? В этом случае вариант с автоматной организацией интерфейса не применим или надо как-то иначе организовать автомат?

Например.
Есть диалог, в котором надо выбрать из плана счетов счет плательщика, ввести сумму платежа и разные другие параметры, а затем нажать кнопку "Сохранить".
По одному из требований бизнес-логики введенные параметры считаются корректными, если на выбранном счете плательщика есть остаток не ниже заданной суммы платежа.
Допустим, решено делать кнопку "Сохранить" доступной для нажатия (Enabled = true) только если вышеозначенное требование удовлетворено. Вопрос юзабилити (на сколько такое "молчаливое" поведение будет понятно пользователю) мы пока не рассматриваем, просто так решено и так надо сделать.
Получается, что после выбора/изменения номера счета плательщика надо проверить остаток на выбранном счете и сравнить его с суммой платежа; тоже самое надо сделать после ввода/изменения суммы платежа. И, в зависимости от соотношения (больше/меньше) остатка на выбранном счете и введенной суммы платежа, надо сделать кнопку "Сохранить" доступной или не доступной.

Как такое запрограммировать с применением конечного автомата?