Здравствуйте, Blazkowicz, Вы писали:
B>Скажите это тем кто пользуется визуальными редакторами GUI.
Хихи. Я с такими людьми не общаюсь.
>Которые поризводители IDE штампуют кто во что горазд без какой-либо совместимости.
Пороть их надо нещадно за то, что они штампуют
YК>Есть совершенно четкое определение контрактного программирования, данное Мейером. И именно о контрактном программировании шла речь в этой ветке, а не о верификации notnull.
В этой ветке я изначально ставил вопрос о неполноте решения с notnull. При чём тут "чёткое определение Мейера"?
M>И независимым от языка, потому как ждать у моря погоды тоже хреново.
Почти так. Для выражения любых мыслей язык всё равно нужен. Другое дело, что он может быть специализированным, как например XMI или OCL. Вообще, подобные механизмы определения контрактов должны разрабатываться с привязкой к MOF. А далее см. Eclipse Modeling Project.
Не успел вчера ответить.
B>>Разумеется нет. Но такой инструментарий должен быть независимым от производителя IDE. R>А, вы про наработки JetBrains? Не в курсе, как там. Oval же — просто библиотека, правда и требует потрошения кода аспектным компилятором.
Овал почти хорош, да. Кой-чего не хватает (см.ниже).
B>>Декларируется в явном виде возможность не задавать значение поля. R>Все равно непонятно, чем это отличается от простой декларации переменной...
Возможностью определять семантику определения в runtime (для чего, собственно, и придуманы аннотации).
B>>public class Profile { B>>@Optional PostalAddress address = new PostalAddress(); // optional = адрес не заполнен, хотя объект под него создан R>Какую смысловую нагрузку несет @Optional для поля address в классе Profile; то есть Profile знает, что его поле address фиктивно? Допустим... и что дальше, как это есть, чем это лучше null?
Тут можно долго фантазировать на самом деле Предлагаю ограничиться следующим: Optional я упомянул для симметрии определению Mandatory. Конкретная реализация валидатора может доопределить семантику в runtime.
R>Что-то мне подсказывает, что от JCP такого счастья ждать в ближайшие годы, как и у моря погоды.
Hibernate привел к появлению JPA. Независимая сторонняя библиотека может сделать то же самое. Какой она должна быть?
1. Аннотации декларируют ограничения. Исчерпывающий набор базовых аннотаций (поддержка OCL) плюс возможность определения пользовательских.
2. API для валидации. Пользователь может расширять базовую семантику в своих валидаторах по принципу:
3. Полноценная поддержка AOP. Хочется определять необходимость валидации для любых методов (в Oval не увидел), например так:
@Valid
public Result execute(@Valid Scenario scenario) {
// сюда мы попадаем только в случае, если объект scenario прошёл валидацию без ошибок
...
return result; // значение будет возвращено только в случае, если оно корректно
}
Здравствуйте, Baudolino, Вы писали:
B>3. Полноценная поддержка AOP. Хочется определять необходимость валидации для любых методов (в Oval не увидел), например так:
не знаю, правильно ли я понимаю, что ты имеешь в виду, но в OVal это есть
Здравствуйте, Baudolino, Вы писали:
B>Не успел вчера ответить.
B>Овал почти хорош, да. Кой-чего не хватает (см.ниже).
Прочитал, говорю сразу — неправда, практически все это есть.
B>Возможностью определять семантику определения в runtime (для чего, собственно, и придуманы аннотации).
Смотрели @Assert (+Groovy) в OVal-е?
И потом, во-первых, мне сложно представить контракты, которые нужно генерировать рефлексией, а во-вторых, надеюсь, мне не наврали (сам не сталкивался, но заинтересовался), что аспектный компилятор можно каким-то образом встроить в runtime, то есть все, что нужно вам — есть: рефлексия, на основе которой вы создаете свои гиперсложные-изменчивые контракты, и некий АОП-JIT, их компилирующий-исполняющий.
B>Тут можно долго фантазировать на самом деле Предлагаю ограничиться следующим: Optional я упомянул для симметрии определению Mandatory. Конкретная реализация валидатора может доопределить семантику в runtime.
Не знаю, честно говоря, так и не понял, о чем речь.
B>1. Аннотации декларируют ограничения. Исчерпывающий набор базовых аннотаций (поддержка OCL) плюс возможность определения пользовательских.
Есть.
B>2. API для валидации. Пользователь может расширять базовую семантику в своих валидаторах по принципу: B>
Есть. Практически дословно.
B>3. Полноценная поддержка AOP. Хочется определять необходимость валидации для любых методов (в Oval не увидел), например так: B>
B>@Valid
B>public Result execute(@Valid Scenario scenario) {
B> // сюда мы попадаем только в случае, если объект scenario прошёл валидацию без ошибок
B> ...
B> return result; // значение будет возвращено только в случае, если оно корректно
B>}
B>
Здравствуйте, rsn81, Вы писали:
R>Вроде тоже есть, конкретно, что не смогли?
Я смотрел только страницу http://oval.sourceforge.net — на знакомство с исходниками нет времени. Если вы имеете в виду probe mode, то я не об этом. Код приведённый на странице выглядит просто жутко. Я имею в виду буквально следующее:
@Constraints({@OCL("name.length > age")})
public class Entity {
@Max(10)
int age;
@MaxLength(20)
String name;
}
public class EntityDAO {
public void save(@Valid Entity entity) throws ValidationFailedException {
// при вызове этого метода происходит валидация параметра entity по всем наложенным ограничениям
}
}
Oval такое поддерживает или нужно всегда использовать probe mode (в котором, как я понял из кода, происходит перехват сеттеров — а как же тогда валидация на сложных ограничениях)?
P.S. NP, я вообще использую для таких вещей фреймворк собственной разработки, в котором как раз собираюсь реализовать описанное
Здравствуйте, Baudolino, Вы писали:
B>Oval такое поддерживает или нужно всегда использовать probe mode (в котором, как я понял из кода, происходит перехват сеттеров — а как же тогда валидация на сложных ограничениях)? Using the probe mode to simplify UI user input validation — вроде бы меня устраивает вполне. Если, как вы говорите, вас такой вариант не устраивает, можно посмотреть в сторону @ValidateWithMethod и @CheckWith: Expressing complex class specific constraints
B>P.S. NP, я вообще использую для таких вещей фреймворк собственной разработки, в котором как раз собираюсь реализовать описанное
В "обычных" классах все еще пользуюсь для этого assert-ами, а OVal использую только для контрактного программирования в BLL(+GUI) и DAL(+DB). Ради одного только NullPointerException усложнять обычную библиотеку OVal-ом, который зовет с собой в гости АОП-компилятор — по-моему, не очень дальновидно.
