M>>Так. Мой код будет перерастать во что-то сложное, а твой не будет? Можно это продемонстрировать? Да, я лично не вижу, как это экстраполируется

_>Ты не понял мою мысль.

Я ее понял

_>Вот смотри, у меня сейчас есть пример для простейшей бизнес-логики. Дальше, берём относительно сложный случай (твой шаг3 скажем) и берём твой сложный код "в лоб" для этого случая. Так вот нам понадобится просто вставить этот твой сложный код прямо в определённую точку моего простого примера. Понятная идея? ) Т.е. грубо говоря при усложнение задачи объём дополнительного кода (возникающего ради статического отлова ошибок) не будет возрастать (относительного моего примера).

Можно это увидеть на полноценном примере? Там всего-то несколько усложнений по сравнению с реальностью

M>>И как показывает твой пример, нам все равно надо отлавливать рантайм-ошибки в зависимости от того, как эти ассерты расставлены. В итоге ответсвенность за логику размыта и стало сложнее проследить, а не забыли ли мы что-либо и правильно ли мы реализовали логику.

_>Ты похоже тут уже пытаешься решить совсем другую задачу.

Да нет. Все ту же Я просто говорю, что твой пример показывает, что с точки зрения программиста все стало сложнее. Где мы проверяем условия статически? А где — в рантайме? Не маскирует ли стат. типизация необходимую проверку в рантайме? В нужном ли месте я поставил стат. типизацию, и правильно ли, что во втором твоем примере происходит рантайм проверка? С ростом количества условий это превратится в непонятный никому звиздец, имхо.

А как только для разруливания и проверки этого звиздеца мы вставляем тесты, как ценность стат. проверок начинает падать экспоненциально.

_>Максимум, что могут наши современные средства, это свести введение правил до действительно одной точки, с автоматическим расползанием их по всему коду. И как раз в таком статическая типизация очень помогает.

Не понял этой фразы и утверждения

_>>>Что касается количества проверок... Ты про что, про размер исходника или про нагрузку процессора в рантайме? )
M>>Нет. Я имел в виду, что вижу по два if'а (грубо говоря) на каждую функцию

_>Ну в исполняемый файл в итоге попадает или один или ноль if'ов. А в исходнике да, разрастаемся... )))

Ну, вообще-то по большому счету глубоко наплевать на то, что попадает в исполняемый файл. Время программиста, который будет все это писать и разбирать потом, важнее намного.

_>>>Вообще то как раз существует и даже прямо в твоём случае. Например при создание нового ордера мы можем точно указать его тип и т.д.
M>>Теоретики такие теоретики. Новый заказ создается из 100% рантайм-данных. И, соотвественно, наделяется всеми свойствами исключительно в рантайме.

_>Ничего подобного. В коде ты легко можешь создать пустой экземпляр ордера (и у него уже не будет тип Unknown, а будет скажем IncreaseDecrease), а потом заполнить его своими рантайм данными с помощью тех же самых функций перевода состояния. И при этом будут автоматически производиться все проверки.

Так. Я про это и говорю: данные приходят строго из рантайма. Про «функции перевода состояния» я слышу уже скоро месяц, как, но никто так и не осилил описать эти «функции состояния» до уровня полноценного примера

И вообще. Что значит «функции состояния»? У нас нет никаких «функций перехода состояния». Изменение суммы заказа может происходить через неделю после того, как заказ создан. При чем тут «функции состояния»? Перед тем, как изменить сумму заказа, заказ будет загружен из базы данных в любом из четырех (из примера) или полутора десятков (в реальности) состояний.

Тут рядом Sinclair недаром просил показать функцию load_order для примера jazzer'а