О обеспечении политики с аспектом
Вопрос
Я использую AspectJ для обеспечения соблюдения политики в целом.
Одна вещь, которую я пытаюсь реализовать сейчас, это то, что в методах сеттера не должно быть логики, кроме простой проверки с гуавой Preconditions.check*
методы
public pointcut withinSetter() :
withincode(public void set*(*));
public pointcut inputValidation() :
call(public void Preconditions.check*(*));
public pointcut setFieldValue() : set(* *);
public pointcut entity() : within(com.mycompany.BaseEntity+);
declare warning :
entity() && withinSetter() && !setFieldValue() && !inputValidation():
"Please don't use Logic in Setters";
Это работает, как и ожидалось, генерируя предупреждения для любого неретентного кода. Тем не менее, это терпит неудачу для таких конструкций:
public void setFoo(final String newFoo) {
Preconditions.checkNotNull(newFoo); // this is OK
Preconditions.checkArgument(
newFoo.matches("\\p{Alpha}{3}"), // this generates a warning
// because String.matches()
// is called
"Foo must have exactly 3 characters!");
this.foo = newFoo;
}
Так что я ищу конструкцию, которая позволила бы любой код, если это происходит внутри параметров к Preconditions.check*
вызов. Есть такая точка?
Решение
Я знаю, что это старый вопрос, но я просто наткнулся на него, искавая что -то еще.
Ответ - нет, потому что в байт -коде JVM нет такой вещи, как «логика внутри check*
позвонить ». Например, newFoo.matches(..)
оценивается до Результат передается Preconditions.checkArgument(..)
, очень нравится это:
boolean match = newFoo.matches("\\p{Alpha}{3}");
Preconditions.checkArgument(match, "Foo must have exactly 3 characters!");
Если бы код был написан таким образом, вы бы выпустили предупреждение, так почему бы, если бы не код Java, возможно, приведет к аналогичному или идентичному байтовому коду, написан как вложенный вызов? ;-)
Обновлять: Я создал небольшой пример:
public class Application {
public static void main(String[] args) {
String newFoo = "Scrum";
boolean match = newFoo.matches("\\p{Alpha}{3}");
checkArgument(
match,
"Foo must have exactly 3 characters!"
);
checkArgument(
newFoo.matches("\\p{Alpha}{3}"),
"Foo must have exactly 3 characters!"
);
}
private static void checkArgument(boolean status, String errorMessage) {
if (!status)
System.out.println(errorMessage);
}
}
Если вы сбрасываете байтовый код, используя javap -c Application
ты видишь это:
Compiled from "Application.java"
public class Application extends java.lang.Object{
public Application();
Code:
0: aload_0
1: invokespecial #8; //Method java/lang/Object."<init>":()V
4: return
public static void main(java.lang.String[]);
Code:
0: ldc #16; //String Scrum
2: astore_1
3: aload_1
4: ldc #18; //String \p{Alpha}{3}
6: invokevirtual #20; //Method java/lang/String.matches:(Ljava/lang/String;)Z
9: istore_2
10: iload_2
11: ldc #26; //String Foo must have exactly 3 characters!
13: invokestatic #28; //Method checkArgument:(ZLjava/lang/String;)V
16: aload_1
17: ldc #18; //String \p{Alpha}{3}
19: invokevirtual #20; //Method java/lang/String.matches:(Ljava/lang/String;)Z
22: ldc #26; //String Foo must have exactly 3 characters!
24: invokestatic #28; //Method checkArgument:(ZLjava/lang/String;)V
27: return
}
Как вы можете видеть, байтовый код строк 3-13 против 16-24 в дампе идентичен, за исключением хранения и повторной загрузки логического значения. Может быть, это иллюстрирует то, что я говорил раньше.