Я должен был бы сказать самовыполнение функций.
(function() { alert("hi there");})();
, поскольку Javascript не имеет области действия блока , можно использовать самовыполняющуюся функцию, если Вы хотите определить локальные переменные:
(function() {
var myvar = 2;
alert(myvar);
})();
Здесь, myvar
, не вмешивается в или загрязняет глобальную область видимости и исчезает, когда функция завершается.
Если вы ищете полноценный механизм проектирования по контракту, я бы посмотрел на некоторые из проектов, перечисленных на странице Википедии для DBC .
Если вы ищете что-то попроще, вы можете взглянуть на класс Preconditions из коллекций Google, который предоставляет метод checkNotNull (). Таким образом, вы можете переписать код, который вы отправили по адресу:
public void myContractualMethod(final String x, final Set<String> y) {
checkNotNull(x);
checkArgument(!x.isEmpty());
checkNotNull(y);
}
Я видел метод Эрика Берка , который примерно похож на следующий. Это элегантное использование статического импорта. Код читается очень хорошо.
Чтобы понять, вот класс Contract
. Здесь он минимальный, но может быть легко заполнен по мере необходимости.
package net.codetojoy;
public class Contract {
public static void isNotNull(Object obj) {
if (obj == null) throw new IllegalArgumentException("illegal null");
}
public static void isNotEmpty(String s) {
if (s.isEmpty()) throw new IllegalArgumentException("illegal empty string");
}
}
А вот пример использования. Метод foo ()
иллюстрирует статический импорт:
package net.codetojoy;
import static net.codetojoy.Contract.*;
public class Example {
public void foo(String str) {
isNotNull(str);
isNotEmpty(str);
System.out.println("this is the string: " + str);
}
public static void main(String[] args) {
Example ex = new Example();
ex.foo("");
}
}
Примечание: при экспериментировании обратите внимание, что может быть ошибка при выполнении этого в пакете по умолчанию. Я определенно потерял клетки мозга, пытаясь это сделать.
Это не дает прямого ответа на ваш вопрос, но я думаю, что часть вашей проблемы заключается в том, что вы переусердствовали с проверкой. Например, вы можете заменить первый тест на:
if (x.isEmpty()) {
throw new IllegalArgumentException("x cannot be empty");
}
и полагаться на Java, чтобы выбросить NullPointerException
, если x
равно null
. Вам просто нужно изменить свой «контракт», чтобы указать, что NPE выдается для определенных типов ситуаций «вы позвонили мне с недопустимыми параметрами».
Я бы использовал аннотации параметров, отражение и общий класс валидатора, чтобы создать средство для всего приложения. например, вы можете закодировать такой метод класса:
.. myMethod (@notNull String x, @notNullorZero String y) {
if (Validator.ifNotContractual(getParamDetails()) {
raiseException..
or
return ..
}
}
Методы класса «размечены», чтобы аннотировать их требования к контракту. Используйте отражение, чтобы автоматически обнаруживать параметры, их значения и аннотации. Отправьте все это в статический класс, чтобы проверить и сообщить результат.
Джаред указал вам на различные инфраструктуры, которые добавляют поддержку DBC в Java.
Лучше всего работает следующее: просто документируйте свой контракт в JavaDoc (или в любой другой структуре документации, которую вы используете; Doxygen поддерживает теги DBC).
Обфускация вашего кода множеством бросков и проверок ваших аргументов не особо полезна для вашего читателя. Документация есть.
При создании таблицы с вложенной таблицей индекс создается автоматически. Место хранения на основе объектов в целом может делать это, поскольку могут быть созданы скрытые таблицы.
Я думаю, что XMLTypes на основе схемы также сделает это.
-121--2132426-Эта статья в Википедии объясняет два алгоритма, которые можно использовать для решения этой проблемы.
-121--4132680-Существует небольшой пакет Java Argument Validation , реализованный как Plain Java. Она поставляется с несколькими стандартными проверками/проверками. И для тех случаев, когда кому-то нужны свои более конкретные проверки, он поставляется с некоторыми вспомогательными методами. Для многократных проверок просто расширьте интерфейс ArgumentValidation, используя собственный класс и создайте класс реализации, который расширен из класса ArgumentValidationImpl.
Не полностью рабочее решение, но в JSR-303 есть предложение по расширению валидации на уровне методов . Поскольку это всего лишь предложение по расширению, реализации JSR-303 могут его игнорировать. Найти реализацию немного сложнее. Я не думаю, что Hibernate Validator поддерживает его, но полагаю, что agimatec-validation имеет экспериментальную поддержку. Я не использовал ни то, ни другое для этой цели, поэтому не знаю, насколько хорошо они работают. Мне было бы интересно узнать, если кто-то попробует.