Pull to refresh

Comments 36

контракты — это хорошо. просто замечательно местами.
я все чаще убеждаюсь — чем больше ограничений накладывается на данные — тем меньше потом глюков будет вылезать в рантайме.
А к eclipse его (процессинг аннотаций) подключить без извратов можно?
Интересно, конечно, но запись условий строками — ад.

Плюс уже есть JSR 303 (Bean Validation), который во многом делает тоже самое (и без строк). Современная реализация Java-контрактов должна быть с ним как-то интегрирована.
Прикольная либа. Правда те проблемы, которые она помогает решить довольно редки, но все же лучше — не хуже :) Вот бы если было что-то подобное для concurrent программирования.
из примера:
  @Ensures({
    "result >= 0",
    "result <= 23"
  })
  int getHour();

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

В чем смысл?
Еще одна парадигма помогает не плодить сущности, в этом и смысл.
Правильно понимаю, что «детали» такого контракта нужно прописывать возле каждого метода, где упоминаются часы — принимаются аргументами или возвращаются в результате? Если так, то тип кажется выгоднее — здесь реализация будет инкапсулирована внутри единтсвенного класса.
А в класе Hour будет поле int для которого будут методы а-ля getValue, setValue для которых и будет таже самая валидация. В чём смысл?
Меньше текста писать (самое главное), более прозрачная структура, масштабируемость, полиформизм и прочие полезности.
Такой класс лучше сделать неизменяемым (value object).
Похоже на ValidationAttribute в c#
Эх, Эйфиль… Красивое название всё таки.
я конечно люблю java, но помоему это какой то костыль
при чем для тех кто слишком тупит чтоб использовать assert )
а у вас асерты в рантайме бегут?
Впринципе можно использовать и ассерты, но анотации ИМХО более читабельны, в отличие от длинных ассертов, всегда прописаны перед классом/методом/параметром (знаешь где искать), и контрактные аннотации можно использовать для генерирования документации.
В аннотациях, хм. Напоминает мою собственную Python-овую библиотеку python-dbc, в которой я решил хранить контракты в docstring-ах (кто не знает Python-а — по сути, это просто комментарии к функциям), после чего меня как за это, так и вообще за идею DbC в Python-е долго ругали на #python :)
Може я что-то не понимаю, но что, программисты из гугла слишком тупыеумные чтоб использовать встроенный assert вместо этого уродливого костыля?
Ну и каким образом данный багрепорт подтверждает вашу точку зрения?

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

int foo()
    pre  ASSUME_EXPR
    post ENSURE_EXPR
  {
    BODY
  }


вместо

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


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

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

Но для этого явно не нужно городить код в строках как сабж.
> 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.
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. Это означает что у ассертов не должно быть побочных эффектов. Этот же момент применим и к контрактам. Они тоже не должны иметь побочных эффектов для корректного функционирования кода.

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

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

От себя замечу, что сложную модель неудобно вписывать в псевдокомментарии или аннотации — у модели появляется собственное состояние, которое надо где-то описать. В общем, наши слоны давно выросли в JavaTESK — расширение Java специальными конструкциями, с поддержкой в Eclipse. Покупайте наших слонов! Впрочем, покупать не получится — JavaTESK выпущен под открытой лицензией.
полистал документацию к проекту — очень много деталей, не понятно, что происходит. Нет ли короткой статьи?
Увы, документация — не самая сильная наша сторона, ресурсов не хватает.
С птичьего полета подход описан в этом документе из параллельного проекта CTESK. Дополнительную информацию можно поискать на основном сайте.
Ну вот да «инструменты подобные CTESK обычно применяются при разработке
программного обеспечения, к надежности которого предъявляются повышенные
требования. Поэтому наиболее перспективными областями применения CTESK являются: ...». Именно такое ощущение у меня и возникло. Тул типа RSL того же. К обычным проектам применим не сразу, тогда как гугловый инструмент, все-таки, выглядит более человеческим — можно применять хоть движку блога: меньшая learning curve, меньшие требования к процессу и т.п.
Совершенно верно, в первую очередь технология разрабатывалась для проектов с повышенными требованиями к надежности. Однако, её можно адаптировать для более широкого класса задач, мы немного работаем в этом направлении. А вот применить эту библиотеку к сложным системам будет ой как непросто.
Тут идет речь о вещах сильно более сложных, чем велосипеды. Потому каждое новое творение по своему уникально.
Я так и знал, что в Гугле не знают, что такое юнит-тестирование.
Контрактное программирование — разумная замена параноидальному TDD. Однако на практике точного javadoc-описание функции и assert-ов бывает более чем достаточно.
Код для проверки в строках аннотаций вводить тяжело, так как отсутствует поддержка GUI.
А можно по-подробней? Мне кажется контракты ортогональны юнит-тестам? Вместе поидее должны давать хороший результат.
Only those users with full accounts are able to leave comments. Log in, please.