Jan 14

In Projekten ist es für den Architekten/Projektleiter oft sehr schwer die Einhaltung der Design/Code Konventionen innerhalb des Projektes zu überwachen. Häufig stellt man leider zu spät fest, das sich manche Entwickler über Konventionen hinweggesetzt haben. So wird man man gerne gegen Anfang der Integrationsphase mit bösen Überaschungen konfrontiert.

Ein paar wenige Verstöße die doch immer wieder auftauchen:

  • System.out.println() wird statt dem Logging verwendet
  • Unerlaubte Zugriffe innerhalb der Schichten (Integration Layer greift auf Domain layer zu)
  • Exceptions werden mit printStackTrace in den System Outputstream geschrieben.

Eine elegante Methode, diese Verstöße zu überwachen und ggf. automatisert zu verhindern lässt sich sehr einfach mit Aspekten umsetzen. Vor allem mit AspectJ 5 braucht man dazu keine ausgelagerten Aspekte schreiben, sondern kann diese über Annotations in einer herkömmliche Java Klasse schreiben.

Die Definition einer Warnung/Fehlermeldung erfolgt durch eine String Konstante. Der Inhalt der Konstante stellt auch später die Meldung dar. Die Konstante muss nun mit der Annotation org.aspectj.lang.annotation.DeclareError (Fehler) bzw. org.aspectj.lang.annotation.DeclareWarning (Warnung) versehen werden. Der Annotation selbst wird die Bedingung (Pointcut) mitgegeben, welche das aktivieren/deaktiveren des Fehlers steuert.

Falls man zum Beispiel die Verwendung von System.out.println() verhindern will, sieht die Definition wie folgt aus

@DeclareError(“get(* System.*) && !get(* System.class)”)

static final String avoidSystemStreams= “System.out || System.in || System.err not erlaubt”;   

Will man eine Warnung definieren, muss die Annotation @DeclareWarning anstelle @DeclareError verwendet werden.Falls nun im Code doch System.out.println verwendet wird, erscheint z.B. im Eclipse folgende Fehlermeldung”System.out || System.in || System.err not erlaubt” AspectJ/de/agimemruli/aspectj/sample BrokenClass.java line 25 

So lassen sich im Prinzip beliebig viele Konventionen überprüfen, allerdings sollte man auch hier das Motto beachten “Weniger ist manchmal mehr” :-) 

Beispiele gibt es hier