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

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

Высокоуровневую логику на типах писать сложно и обычно нерентабельно, и это обычно никто не делает. По вот пример ошибки в твоей задаче, с которой типы могут помочь: представь, что все три флага выше имеют просто тип boolean. Программист может случайно ошибиться, например, в порядке аргументов, и вместо того, чтобы пометить заказ как "предоплачен", пометить его как "отправлен". Если же вместо boolean мы будем использовать три разных типа, с двумя значениями каждый, такую ошибку будет очень трудно совершить случайно. Точно так же, можно использовать разные типы для количества и цены товара.

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

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

Высокоуровневую логику на типах писать сложно и обычно нерентабельно, и это обычно никто не делает. Но вот пример ошибки в твоей задаче, с которой типы могут помочь: представь, что все три флага выше имеют просто тип boolean. Программист может случайно ошибиться, например, в порядке аргументов, и вместо того, чтобы пометить заказ как "предоплачен", пометить его как "отправлен". Если же вместо boolean мы будем использовать три разных типа, с двумя значениями каждый, такую ошибку будет очень трудно совершить случайно. Точно так же, можно использовать разные типы для количества и цены товара, и т.д. Компилятор может проверять, что мы случайно не складываем погонные метры с килограммами, или что мы не ищем значение в килограммах внутри списка, элементы которого являются "количеством ящиков".