superman_cherry Apr 2 2018 at 17:12

Программирование согласно контракту на JVM

4 min

Programming*Java*Kotlin*

From sandbox

+15

Comments 8

visirok Apr 2 2018 at 21:48

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

potan Apr 3 2018 at 10:05

А есть ли системы формальной верификации, поддерживающие данные контракты? То есть, например, что бы по коду с контрактами можно было сгенерировать задание для SMT-солвера, которое ищет нарушение контракта?

vampirit Apr 3 2018 at 15:10

"По сути, условия быстро перестают работать. Нет смысла запускать код, если в конце, вычисление завершится неудачно из-за неправильного предположения."

Я бы сказал не "условия перестают работать", они все таки не перестают.
А "условия прерывают работу".

Спасибо за перевод

superman_cherry Apr 3 2018 at 15:10

Благодарю за дополнение!!!

SlavniyTeo Apr 5 2018 at 10:49

Заинтересовавшимся программированием по контракту рекомендую почитать статьи Сергея Теплакова здесь.

Ztare Apr 5 2018 at 13:35

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

POPSuL Apr 5 2018 at 14:43

Статья интересная, но меня немного смутил последний пример (я не пишу на котлине, хотя немного тыкал его):

    require(amount <= BigDecimal.ZERO)
    require(source.getBalance() <= BigDecimal.ZERO)

Мне кажется что логичнее было бы использовать >= вместо <=. Я, как человек не знающий как реализована функция require(), прочитал это как "требуется чтобы сумма была меньше или равна нулю, и чтобы баланс переводящего был меньше или равен нулю".
Как по мне, поведение классической функции assert() является более логичным.

AndreyRubankov Apr 27 2018 at 10:58

А как же Guava Preconditions для Java?

google.github.io/guava/releases/21.0/api/docs/com/google/common/base/Preconditions.html

Show the best of all time