Здравствуйте, Mamut, Вы писали:

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

Ну смотри, у тебя же классический конечный автомат из 3+1 состояний (3 реальных и 1 (Unknown) нужное для статической типизации), которые я все уже описал в коде. Ну точнее я не ввёл формально состояние Increase&Decrease, но только потому что там не было функции переводящей в него (мы же не можем сделать Unsend ордера). Соответственно какие бы сложные условия ты не добавлял на своих следующих шагах, это просто приведёт к усложнению кода перехода между состояними (грубо говоря твой "код в лоб" будет переноситься в некую сложную функцию типа CanDecrease, вызываемую в точке if(Type==OrderType::Unknown&&CanDecrease()) throw ... функции Decrease).

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

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

Ну для начала статическая типизация не устраняет сами ошибки, а переводит их возникновение из времени исполнения во время компиляции. Что мы и видим в моём примере. Естественно переводятся во время компиляции только те проверки, для которых достаточно знаний на момент компиляции. Если в коде используется очень много рантайм данных, то никакая статическая типизация не позволит вынести много проверок во время компиляции. Но какие-то выносятся и в таком случае, что и демонстрирует мой пример. А вот если рантайм данных не много (ну в смысле не самих данных, а грубо говоря типов определяемых динамически), то подобный подход становится суперэффективным. С экстремум в виде 100% гарантии безошибочности кода при полном отсутствие динамически определяемых типов.

Что касается количества проверок... Ты про что, про размер исходника или про нагрузку процессора в рантайме? ) Если про первое, то да, действительно размер исходника возрастает. Но это цена за перевод ошибок из времени исполнения во время компиляции. Если же говорить о втором, то там как раз количество рантайм проверок снижается (думаю же для тебе не откровения, что весь код после "if(X&&", где X — это false времени компиляции, компилятор полностью выкидывает? Кстати, в том же D это значительно нагляднее выглядит, благодаря наличию static if, но результат тот же самый), так что этот самый "разросшийся" код по быстродействию эффективнее твоего варианта "в лоб".

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

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

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

Здравствуйте, Mamut, Вы писали:

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

Ну смотри, у тебя же классический конечный автомат из 3+1 состояний (3 реальных и 1 (Unknown) нужное для статической типизации), которые я все уже описал в коде. Ну точнее я не ввёл формально состояние Increase&Decrease, но только потому что там не было функции переводящей в него (мы же не можем сделать Unsend ордера). Соответственно какие бы сложные условия ты не добавлял на своих следующих шагах, это просто приведёт к усложнению кода перехода между состояними (грубо говоря твой "код в лоб" будет переноситься в некую сложную функцию типа CanDecrease, вызываемую в точке if(Type==OrderType::Unknown&&CanDecrease()) throw ... функции Decrease).

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

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

Ну для начала статическая типизация не устраняет сами ошибки, а переводит их возникновение из времени исполнения во время компиляции. Что мы и видим в моём примере. Естественно переводятся во время компиляции только те проверки, для которых достаточно знаний на момент компиляции. Если в коде используется очень много рантайм данных, то никакая статическая типизация не позволит вынести много проверок во время компиляции. Но какие-то выносятся и в таком случае, что и демонстрирует мой пример. А вот если рантайм данных не много (ну в смысле не самих данных, а грубо говоря типов определяемых динамически), то подобный подход становится суперэффективным. С экстремум в виде 100% гарантии безошибочности кода при полном отсутствие динамически определяемых типов.

Что касается количества проверок... Ты про что, про размер исходника или про нагрузку процессора в рантайме? ) Если про первое, то да, действительно размер исходника возрастает. Но это цена за перевод ошибок из времени исполнения во время компиляции. Если же говорить о втором, то там как раз количество рантайм проверок снижается (думаю же для тебе не откровения, что весь код после "if(X&&", где X — это false времени компиляции, компилятор полностью выкидывает? Кстати, в том же D это значительно нагляднее выглядит, благодаря наличию static if, но результат тот же самый), так что этот самый "разросшийся" код по быстродействию эффективнее твоего варианта "в лоб".

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

Вообще то как раз существует и даже прямо в твоём случае. Например при создание нового ордера мы можем точно указать его тип и т.д. Проблема в том, что полностью уйти от рантайм данных в твоём случае нельзя и соответственно нельзя полностью убрать рантайм проверки. Но и частичный перевод ошибок во время компиляции тоже может быть полезен. )