Хорошая библиотека Design-by-Contract для Java?

Ответ 1

Есть хороший обзор на WikiPedia о проекте по контракту, в конце раздела есть раздел, касающийся языков с сторонние библиотеки поддержки, в которую входит хорошая серия библиотек Java. Большинство этих библиотек Java основаны на Java Assertions.

В случае, когда вам нужна только Precondition Checking, также есть легкий Validate Method Arguments в SourceForge под Java Argument Validation (обычная реализация Java).

В зависимости от вашей проблемы, возможно, OVal, для проверки свойств полей/свойств является хорошим выбором. Эта структура позволяет помещать ограничения во всевозможные формы (аннотации, POJO, XML). Создавайте ограничения для клиентов через POJO или языки сценариев (JavaScript, Groovy, BeanShell, OGNL, MVEL). И он также участвует в реализации Программирование по контракту.

Ответ 2

В Google есть библиотека с открытым исходным кодом, называемая контракты для java.

Контракты для Java - это наш новый инструмент с открытым исходным кодом. Предпосылки, постусловия и инварианты добавляются как булевские выражения Java внутри аннотаций. По умолчанию они ничего не делают, но включены через JVM аргумент, theyre проверен во время выполнения.

• @Requires, @Ensures, @ThrowEnsures and @Invariant specify contracts as Java boolean expressions
• Contracts are inherited from both interfaces and classes and can be selectively enabled at runtime

контракты для java.

Ответ 3

Я тестировал контракт 4J один раз и нашел его полезным, но не идеальным. Вы создаете контракты для вызовов и после вызовов методов и инвариантов по всему классу.

Контракт создается как утверждение для метода. Проблема заключается в том, что сам контракт записывается в строку, поэтому у вас нет поддержки IDE для контрактов или времени компиляции, если контракт все еще работает.

Ссылка на библиотека

Ответ 4

Прошло много времени с тех пор, как я просмотрел их, но нашел несколько старых ссылок. Один из них был для JASS.

Другой, который я использовал (и любил), был iContract от Reliable Systems. У него была задача ant, которую вы выполнили бы как препроцессор. Тем не менее, я не могу найти его с помощью некоторых поисковых запросов Google, похоже, что он исчез. Исходный сайт теперь является фермой ссылок. Проверьте эту ссылку для некоторых возможных способов добраться до нее.

Ответ 5

Существует расширение Groovy, которое позволяет Design by Contract (tm) в Groovy/Java-коде - GContracts. Он использует так называемые аннотации замыкания для указания инвариантов классов, пред- и постусловий. Примеры можно найти в викторике проекта github.

Основное преимущество: это только одна банка без внешних зависимостей, и ее можно решить с помощью репозиториев, совместимых с Maven, поскольку она была помещена в центральный репозиторий Maven.

Ответ 6

Я настоятельно рекомендую вам рассмотреть язык моделирования Java (JML).

Ответ 7

Я думаю, что многие библиотеки DbC были перекрыты встроенным ключевым словом assert, введенным с Java 1.4:

• он встроен, никакой другой библиотеки не требуется
• работает с наследованием
• вы можете активировать/деактивировать на основе пакета
• легко рефакторинг (например, никаких утверждений в комментариях)

Ответ 8

Я лично считаю, что библиотеки DbC, доступные в настоящее время, оставили желать лучшего, ни одна из библиотек, которые я смотрел, не играла хорошо с Bean Validation API.

Библиотеки, на которые я смотрел, были документированы здесь

В API Bean для проверки достоверности есть много перекрестков с концепциями DbC. В некоторых случаях Bean API проверки не может использоваться как простой POJO (управляемый кодом без CDI). IMO-оболочка вокруг Bean Validation API должна быть достаточной.

Я обнаружил, что существующие библиотеки немного сложны для добавления в существующие веб-проекты, учитывая, что они реализованы либо с помощью AOP, либо с помощью инструментария байтового кода. Вероятно, с появлением Bean API проверки такой сложности для реализации DbC является необоснованным.

Я также задокументировал свой rant в этой post и надеюсь построить небольшую библиотеку, которая использует Bean API проверки

Ответ 9

Если вам нужна простая и простая базовая поддержка для выражения ваших контрактов, посмотрите на valid4j (найденный на Maven Central как org.valid4j: valid4j). Он позволяет вам выражать свои контракты с помощью обычных шаблонов hamcrest в виде простого кода (без комментариев и комментариев).

Для предварительных условий и постусловий (в основном утверждения → throwing AssertionError):

import static org.valid4j.Assertive.*;

require(inputList, hasSize(greaterThan(0)));
...
ensure(result, lessThan(4.0));

Если вас не устраивает глобальная политика по умолчанию (throwing AssertionError), valid4j предоставляет механизм настройки, который позволяет вам предоставить собственную реализацию org.valid4j.AssertiveProvider.

Ссылки:

• http://www.valid4j.org/
• https://github.com/helsing/valid4j

Ответ 10

Я бы предложил комбинацию из нескольких инструментов:

• Java assert condition... или более продвинутый Groovy cousin, Guava Preconditions.checkXXXX(condition...) и Verify.verify(condition...), или библиотека например AssertJ, если все, что вам нужно, это просто выполнить простые проверки в вашем "основном" или "тестовом" коде.

• вы получите больше возможностей с помощью инструмента, такого как OVal; он может проверять оба объекта, а также аргументы и результаты метода, вы также можете запускать проверки вручную (например, показывать ошибки проверки в пользовательском интерфейсе перед вызовом метода). Он может понимать существующие аннотации, например, от JPA или javax.validation (например, @NotNull, @Pattern, @Column), или вы можете писать встроенные ограничения, такие как @Pre(expr="x >= 0 && x <= y"). Если аннотация @Documented, проверки будут также видны в Javadocs (вам также не нужно их описывать).

• OVal использует отражение, которое может вызвать проблемы с производительностью и другие проблемы в некоторых средах, таких как Android; то вы должны рассмотреть инструмент, например Google Cofoja, который имеет меньше функциональности, но зависит от инструмента обработки аннотации времени компиляции вместо отражения