Google упрощает контрактное программирование

[@cleg]

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

[@halyavin]

А к eclipse его (процессинг аннотаций) подключить без извратов можно?

[@proxiper]

Интересно, конечно, но запись условий строками — ад.

Плюс уже есть JSR 303 (Bean Validation), который во многом делает тоже самое (и без строк). Современная реализация Java-контрактов должна быть с ним как-то интегрирована.

[@funca]

из примера:

  @Ensures({
    "result >= 0",
    "result <= 23"
  })
  int getHour();

Кажется, проблема этого кода в том, что getHour() возрващает абстактный int, вместо собственно «часов». Если завести специальный тип Hour (у нас ведь ООП в конце-концов), то вся эта атрибутика будет не особенно нужна:

class Hour {...}
Hour getHour();

В чем смысл?

[@funca]

Правильно понимаю, что «детали» такого контракта нужно прописывать возле каждого метода, где упоминаются часы — принимаются аргументами или возвращаются в результате? Если так, то тип кажется выгоднее — здесь реализация будет инкапсулирована внутри единтсвенного класса.

[@valodzka]

А в класе Hour будет поле int для которого будут методы а-ля getValue, setValue для которых и будет таже самая валидация. В чём смысл?

[@Sap_ru]

Меньше текста писать (самое главное), более прозрачная структура, масштабируемость, полиформизм и прочие полезности.

[@viat0r]

Такой класс лучше сделать неизменяемым (value object).

[@FanKiLL]

Похоже на ValidationAttribute в c#

[@Pilot34]

в c# есть нормальные контракты

[@S0ulReaver]

Эх, Эйфиль… Красивое название всё таки.

[@ScratchBoom]

я конечно люблю java, но помоему это какой то костыль

[@vgrichina]

при чем для тех кто слишком тупит чтоб использовать assert )

[@shalomman]

а у вас асерты в рантайме бегут?

[@jzelenkov]

Впринципе можно использовать и ассерты, но анотации ИМХО более читабельны, в отличие от длинных ассертов, всегда прописаны перед классом/методом/параметром (знаешь где искать), и контрактные аннотации можно использовать для генерирования документации.

[@Honeyman]

В аннотациях, хм. Напоминает мою собственную Python-овую библиотеку python-dbc, в которой я решил хранить контракты в docstring-ах (кто не знает Python-а — по сути, это просто комментарии к функциям), после чего меня как за это, так и вообще за идею DbC в Python-е долго ругали на #python :)

[@vgrichina]

Може я что-то не понимаю, но что, программисты из гугла слишком тупыеумные чтоб использовать встроенный assert вместо этого уродливого костыля?

[@aspect]

Если бы понимал, то знал бы, что жабоассерт не предназначен для контрактного программирования

bugs.sun.com/view_bug.do?bug_id=4449383

[@vgrichina]

Ну и каким образом данный багрепорт подтверждает вашу точку зрения?

В итоге просто предлагается синтаксический сахар для того же ассерта:

int foo()
    pre  ASSUME_EXPR
    post ENSURE_EXPR
  {
    BODY
  }

вместо

  int foo() {
    assert ASSUME_EXPR;
    try {
      BODY
    } finally {
      assert ENSURE_EXPR;
    }
  }

Не вижу тут какой-то действительно принципиальной разницы. Ну другая форма записи немного, но что это меняет по существу? Ну если это на уровне языка сделано – еще ясно зачем, но когда в виде кривого костыля – непостижимо.

Тогда уже можно начать утверждать что в Си невозможно ООП потому что там нет для него синтаксического сахара.

[@aspect]

Главная претензия к ассертам в том, что они громко роняют приложение в дебаге и совершенно не работаю в релизе.
Лично мне гораздо ближе спринговые ассерты, которые можно перехватить и обработать, в отличие от простого, в котором сделано все чтобы не было соблазна восстановиться (Гугловые аннотации мне не нравятся)

[@vgrichina]

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

Но для этого явно не нужно городить код в строках как сабж.

[@aspect]

> Do not use assertions for argument checking in public methods.
> Do not use assertions to do any work that your application requires for correct operation.

[@vgrichina]

1. Вы бы указывали источник цитирования. Ну ладно есть гугл, это не проблема – download.oracle.com/javase/1.4.2/docs/guide/lang/assert.html

2. Эти два пункта применимы и к Гугловской библиотеке. Если не выдирать их из контекста а посмотреть на причины.

Do not use assertions for argument checking in public methods. Этот пункт обоснован что параетры функции должны 1) проверятся всегда 2) ошибка должна кидать документированное исключение а не любое. Контракты никак не решают пункт 2), да и насчет пункта 1) не уверен.

Кстати в багрепорте почему-то упоминается что сейчас мол приходится повторять такой код:

if (! some_precondition_assertion)
                throw new PreconditionException();

Хотя явно никто не мешает вынести его в отдельную функцию чтоб можно было писать например: check(some_precondition_assertion).

Do not use assertions to do any work that your application requires for correct operation. Это означает что у ассертов не должно быть побочных эффектов. Этот же момент применим и к контрактам. Они тоже не должны иметь побочных эффектов для корректного функционирования кода.

Короче ваш комментарий к сожалению не отстаивает вашу точку зрения.

[@aspect]

>вынести его в отдельную функцию чтоб можно было писать например
отчего же, очень удобно

static.springsource.org/spring/docs/3.0.x/api/org/springframework/util/Assert.html

[@vgrichina]

Я о том же. Это автор багрепорта почему-то не подумал о таком варианте.

[@allex]

Можно только посоветовать гугловым программистам гуглить, перед тем, как изобретать велосипед:
JML — Java Modeling Language.
Статья Design by Contract with JML от 2006 года.
И это не единственная попытка.

От себя замечу, что сложную модель неудобно вписывать в псевдокомментарии или аннотации — у модели появляется собственное состояние, которое надо где-то описать. В общем, наши слоны давно выросли в JavaTESK — расширение Java специальными конструкциями, с поддержкой в Eclipse. Покупайте наших слонов! Впрочем, покупать не получится — JavaTESK выпущен под открытой лицензией.

[@pyatigil]

полистал документацию к проекту — очень много деталей, не понятно, что происходит. Нет ли короткой статьи?

[@allex]

Увы, документация — не самая сильная наша сторона, ресурсов не хватает.
С птичьего полета подход описан в этом документе из параллельного проекта CTESK. Дополнительную информацию можно поискать на основном сайте.

[@pyatigil]

Ну вот да «инструменты подобные CTESK обычно применяются при разработке
программного обеспечения, к надежности которого предъявляются повышенные
требования. Поэтому наиболее перспективными областями применения CTESK являются: ...». Именно такое ощущение у меня и возникло. Тул типа RSL того же. К обычным проектам применим не сразу, тогда как гугловый инструмент, все-таки, выглядит более человеческим — можно применять хоть движку блога: меньшая learning curve, меньшие требования к процессу и т.п.

[@allex]

Совершенно верно, в первую очередь технология разрабатывалась для проектов с повышенными требованиями к надежности. Однако, её можно адаптировать для более широкого класса задач, мы немного работаем в этом направлении. А вот применить эту библиотеку к сложным системам будет ой как непросто.

[@philpirj]

Я так и знал, что в Гугле не знают, что такое юнит-тестирование.

[@Throwable]

Контрактное программирование — разумная замена параноидальному TDD. Однако на практике точного javadoc-описание функции и assert-ов бывает более чем достаточно.
Код для проверки в строках аннотаций вводить тяжело, так как отсутствует поддержка GUI.