Выношу из соседнего обсуждения

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

, так как там много флейма и отсутсвие конструктива.

Мне просто действительно интересно. Многие утверждают, что типы помогают (чуть ли не) во всем, вплоть до того, что «тайпчекер проверяет именно логику».

У меня есть простейшая задача, мне просто интересно, как она будет решаться типами, и/или как типы могут помочь ее решить. Самое главное, если вся логика упаковывается в типы, каким образом проверяется правильность реализации этой логики на типах? Свое решение «в лоб» я тоже напишу, естественно Языки программирования — любые Но желательно приближенные к реальному миру (то есть те, что хоть в какой-то мере используются в природе).

Исходные данные:
— есть заказ
-- он может быть отправлен или неотправлен
-- он может быть предоплачен или не предоплачен
-- он может быть помечен, как несущий риск или не помечен

Что с заказом можно сделать:

— Можно изменить сумму заказа: увеличить или уменьшить (в реальности это конечно сложнее, так как изменяется не сумма, а товары в заказе: они могут добавляться, изменяться, добавляться скидки и штрафы и многое другое. И сумма заказа — это сумма товаров. Но для простоты возьмем именно этот случай).


Собственно задача. Мы будем эмулировать реальную разработку, в которой требования меняются. Мне интересно, как будет меняться реализация с типами по мере изменения требований. Все крутится вокруг изменения суммы. Для спортивности: не смотрите в следующий шаг, пока не реализован первый шаг.

Шаг 1.

если заказ неотправлен и непредоплачен, можно увеличивать и уменьшать

если заказ отправлен, нельзя увеличивать, можно уменьшать

если сумма увеличивается, мы должны провести risk check. если risk check не проходит, товар никак не помечается, но изменение суммы не проходит

если товар помечен, как risk, то изменять сумму нельзя

Шаг 2.

Изменение суммы:

Все то же самое, что и в шаге первом, только:

увеличивать можно на max(фиксированная сумма1, процент1 от оригинальной суммы заказа)

уменьшать можно на max(фиксированная сумма2, процент2 от оригинальной суммы заказа),
где сумма1, сумма2, процент1, процент2 — это конфигурация, считываемая из базы данных

Если изменение не попадает в эти рамки, то увеличить/уменьшить нельзя


Шаг 3.

Все то же самое, что и в шаге 2. Дополнительно:

если заказ предоплачен (неважно, отправлен или нет), можно увеличивать сумму, если это разрешено конфигурацией магазина. Сумма, на которую можно увеличивать высчитывается, как в шаге 2

если заказ предоплачен, неотправлен, и сумма увеличивается, надо сделать auth-запрос в банк. если он не срабатывает, увеличить нельзя.

если заказ предоплачен, отправлен, и сумма увеличивается, надо сделать auth-запрос в банк на разницу в сумме, а потом сделать capture запрос на всю сумму. Если хоть один из них не срабатывает, увеличить нельзя.