О применении политики с AspectJ - PullRequest
Новая
       22

О применении политики с AspectJ

2 голосов
/ 27 апреля 2011

Я использую 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*.Есть ли такой pointcut?

1 Ответ

1 голос
/ 10 августа 2013

Я знаю, что это старый вопрос, но я наткнулся на него, ища что-то еще.

Ответ - нет, потому что в байт-коде 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 в дампе идентичен, за исключением хранения и повторной загрузки логического значения. Может быть, это иллюстрирует то, что я сказал раньше.

...