M>>Ну, начинается Вот не вижу я, чтобы он «естественно легко экстраполируется»

_>грубо говоря твой "код в лоб" будет переноситься в некую сложную функцию типа CanDecrease, вызываемую в точке if(Type==OrderType::Unknown&&CanDecrease()) throw ... функции Decrease).

_>Ты действительно видишь здесь что-то сложное? )

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


M>>Ну а по коду видно, что проверок стало в два раза больше, а простор для ошибок — точно такой же, как и без них

_>Ну для начала статическая типизация не устраняет сами ошибки, а переводит их возникновение из времени исполнения во время компиляции. Что мы и видим в моём примере. Естественно переводятся во время компиляции только те проверки, для которых достаточно знаний на момент компиляции.

Ну, я имею в виду, что в твоем примере все равно все упирается в то, расставил ли кто-нибудь static_assert'ы по коду. Если по коду есть хотя бы минимальное тестирование (а логику проверять надо), то их полезность по сравнению с динамической типизацией падает экспоненциально. И как показывает твой пример, нам все равно надо отлавливать рантайм-ошибки в зависимости от того, как эти ассерты расставлены. В итоге ответсвенность за логику размыта и стало сложнее проследить, а не забыли ли мы что-либо и правильно ли мы реализовали логику.

_>Что касается количества проверок... Ты про что, про размер исходника или про нагрузку процессора в рантайме? )

Нет. Я имел в виду, что вижу по два if'а (грубо говоря) на каждую функцию

_>>>P.S. В случае использования только известных на момент компиляции (т.е. не загружаемых из БД, а скажем создаваемых в коде) order'ов, все рантайм проверки можно полностью выкинуть из кода и тогда данный подход соответственно превращается из "необязательной дополнительной фичи" в наиболее оптимальное решение со всех точек зрения.
M>>За пределами теоретических изысканий таких Order'ов в природе не существует

_>Вообще то как раз существует и даже прямо в твоём случае. Например при создание нового ордера мы можем точно указать его тип и т.д.

Теоретики такие теоретики. Новый заказ создается из 100% рантайм-данных. И, соотвественно, наделяется всеми свойствами исключительно в рантайме.

_>P.S. Да, а вообще вся эта ваша архитектура выглядит вообще очень сомнительно и криво. Т.к. по нормальному надо не отлавливать запрещённые пользователю действия и выводить сообщение об ошибке, а просто не позволять их пользователю инициировать. _>Т.е. должна быть функция типа CanIncrease(order), которая вызывается из интерфейса пользователя и соответственно ему не отображается никаких кнопок, которые могут инициировать Increase.

Боже, какие вы все теоретики. /o\ Кнопочки. В GUI. Не выводить. О чем вы все?

У меня может прийти 15 000 автоматических запросов на изменение суммы заказа. Просто потому что магазин так решил. Мы должны вернуть этому магазину внятные сообщения, что «нет, дядя, для таких-то и таких-то заказов это нельзя потому что

Автор: Mamut
Дата: 06.02.15

».

А пропоненты стат. типизации пока не осилили даже не то, что по ссылке, а простую задачу с тремя-четырьмя условиями Несмотря на все пафосные заявления. Все заканчивается после двух условий и заявления «ну, дальше все понятно/очевидно/экстраполируется»