To start with here's a simplified version of the trait that I wanted to intercept:

trait MyTrait {
    var someStuff = "someStuff"
    def someMethod() : String = {
        "do something"
    }
}

class SomeClass extends MyTrait

As I wanted to intercept the constructor and some method calls I defined my aspect like this:

public aspect MyAspect {

	public pointcut newInstance() : execution(MyTrait+.new(..));

	public pointcut someInvocation() : execution(String MyTrait+.someMethod(..));

	after() : newInstance() {
	    System.out.println("after MyTrait constructor invocation");
	}

	after() : someInvocation() {
	    System.out.println("after someMethod invocation");
	}
}

Runnning the code I got quite puzzled that the method invocation pointcut worked fine, but not the constructor pointcut. After consulting the AspectJ reference and convincing myself that the pointcut definition was ok, I had a closer look at the byte code. As we don't have traits in Java the byte code for my trait becomes equivalent to the following pseudo-javacode:

public interface MyTrait extends scala.ScalaObject{
    public String someMethod();
}

public abstract class MyTrait$class extends java.lang.Object{
    public static String someMethod(MyTrait myTrait) {
      // invoke someMethod
    }
    public static void $init$(MyTrait myTrait) {
      // some init stuff
    }
}

So in bytecode I've got an interface and a class with some static method calls. The stuff that goes in the constructor of my trait is done in the $init$ method of the MyTrait$class class. And that's the reason why my pointcut won't work. So actually I have to intercept the $init$ method of the MyTrait$class to get what i want:

public pointcut newInstance() : execution(void MyTrait$class.$init$(..));

Recipe

So how can you shape up the code? Yet better, how can you prevent that the code turns into spaghetti in the first place? One way of looking at architectural requirements is that they are crosscutting concerns that are scattered throughout the software. As such, they can be implemented and enforced by using AOP, aspect-oriented programming. The recipe is pretty straight forward:

1. Implement a pointcut that finds the violations of your architecture.
2. Implement an advice that notifies you about the violations.
3. Wrap the pointcut and the advice into an aspect.
4. Refactor your code and exercise your aspect until all architectural violations have been removed.

Example

This recipe of using aspects as a way of enforcing architectural rules can be applied in any kind of project, for example to enforce the MVC pattern, to separate one domain from another in a DDD project and so on. In this particular example, the application is based on a three layer architecture. The top layer being the GUI layer, the middle layer is the service layer and then there is the DAO layer in the bottom. Each layer has a separate package, as stated below:

SomeGui.java package com.jayway.application.gui; /** Simplistic GUI */ public interface SomeGui { /** Renders the GUI */ void render(); } SomeService.java package com.jayway.application.service; /** Simplistic Service */ public interface SomeService { /** Executes some service */ void service(); } SomeDao.java package com.jayway.application.dao; /** Simplistic DAO */ public interface SomeDao { /** * Finds something in the DAO * @return some data */ public Object find(); }

Architectural Rules

Four architectural rules have been defined:

1. The GUI layer must not access the DAO layer
2. The Service layer must not access the GUI layer
3. The DAO layer must not access the Service layer
4. The DAO layer must not access the GUI layer

These rules are the candidates for defining the pointcuts that should be implemented. An example of code that would violate the first rule is:

BadGuiImpl.java

/**
 * Bad GUI implementation that violates the architectural rule
 * because it calls a method in the DAO layer
 */
public class BadGuiImpl implements SomeGui {

    private SomeService someService;
    private SomeDao someDao;

    @Override
    public void render() {
        // it is ok to use the service...
        someService.service();

        // ...but it is not ok to call the DAO directly
        someDao.find();    

        // more rendering
    }
}

Using AspectJ, two pointcuts have been implemented to trap the violation. Additionally, AspectJ also provides the @DeclareError annotation that can be used for the advice implementation. Finally, an aspect that comprises the pointcuts and the advice has been created:

ArchitecturalEnforcement.java

/**
 * The aspect that is responsible for architecture enforcement:
 * The GUI layer must not access the DAO layer.
 */
@Aspect
public class ArchitecturalEnforcement {

    /** Pointcut for finding join points inside the GUI layer */
    @Pointcut("within(*..*gui..*)")
    public void withinGui() {}

    /** Pointcut for finding method calls to the DAO layer */
    @Pointcut("call(* *..*.dao..*(..))")
    public void callDao(){}

    /** Advice that defines an error when a GUI method calls a method in the DAO layer */
    @DeclareError("withinGui() && callDao()")
    private static final String GUI_MUST_NOT_USE_DAO = "GUI must not access DAO";
}

Exercise the Aspect

How should you use your aspects to enforce the architecture? Since we now have the tools to automate the architectural review, you should use them frequently. AspectJ has support for compile time weaving which means that the advices can be woven into their corresponding join points during source code compilation. The aspectj-maven-plugin can do it for you:

pom.xml

<dependencies>
    <dependency>
        <groupId>org.aspectj</groupId>
        <artifactId>aspectjrt</artifactId>
        <version>1.6.7</version>
    </dependency>
</dependencies>
    ...
<build>
    <plugins>
        <plugin>
            <groupId>org.codehaus.mojo</groupId>
            <artifactId>aspectj-maven-plugin</artifactId>
            <version>1.3</version>
            <configuration>
                <complianceLevel>1.6</complianceLevel>
            </configuration>
            <executions>
                <execution>
                    <goals>
                        <goal>compile</goal>   <!-- Weaves the main classes -->
                        <goal>test-compile</goal>   <!-- Weaves the test classes -->
                    </goals>
                </execution>
            </executions>
        </plugin>
    </plugins>
</build>

Result

If you have put everything together correctly, you will find that you will get a compile time error when you attempt to execute mvn compile:

[[INFO] [aspectj:compile {execution: default}]
[ERROR] "GUI must not access DAO"
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Compiler errors:
error at someDao.find();
^^^^^^^^^^^^^^
/home/mattias/architectural-enforcement/src/main/java/com/jayway/application/gui/BadGuiImpl.java:20:0::0 "GUI must not access DAO"
	see also: /home/mattias/architectural-enforcement/src/main/java/com/jayway/application/aspects/ArchitecturalEnforcement.java:1::0

You can also see the error in your Eclipse IDE if you are using the AJDT - AspectJ Development Tools plugin:

Notably, the implementation above was just one of the stated rules. The implementation of all four rules together with some examples that break them and the Maven pom file are available for download for your convenience.

Considerations

There are some things that you may want to consider before introducing aspects as a tool for automated architectural enforcement:

• Error or Warning

  A compile time error is a powerful tool that prevents the developer to commit any code that does not conform to the architectural rules (presumed, of course, that the code is actually compiled before being checked in). A less brutal way of introducing aspects as a part of architectural review is to use the @DeclareWarning annotation rather than the @DeclareError that was used in the example. Consequently, any architectural offenders will be punished with a compiler warning rather than a compiler error.

• Performance

  The compile time will increase when you add more architectural rules that should be obeyed, that is when you add more pointcuts. Likewise, the compile time will also increase when your code base grows, because of the increasing number of join points in the code. By limiting the aspectj-maven-plugin to certain maven profiles, the developers only have to verify that their particular module conforms to the rules. Alternatively, all modules can be verified by the integration server during nightly builds. The drawback is that the advantage of having the architecture enforced before the code is committed to the version control system will be lost.

• Limitation

  The aspect above can only trap architectural violations when a method is being called. Regrettably, any unused declaration that would violate the architecture will pass unnoticed:

  AnotherBadGuiImpl.java

  package com.jayway.application.gui;
  
  import com.jayway.application.dao.SomeDao;
  
  /**
   * Another bad GUI implementation that violates the architectural rule
   * because it has references to the DAO layer.
   * However, these errors will remain undetected by AspectJ.
   */
  public class AnotherBadGuiImpl implements SomeGui {
  
      /** Unused DAO reference */
      private SomeDao someDao;
  
      /**
       * Setter method that for some obscure reason adds a DAO to the GUI
       * @param someDao A DAO reference that is not found by the pointcut
       */
      public void setDao(SomeDao someDao) {
          this.someDao = someDao;
      }
  
      @Override
      public void render() {
          // valid gui rendering that does not use the dao reference
      }
  }
  

  One solution is to create another pointcut, such as @Pointcut("set(*..*.*dao*..* *)"), that traps the assignment of the someDao member variable.

Wrap Up

Education of the developers and repeated manual code reviews have been the traditional ways of improving software architecture. Unfortunately, it is not good enough. It is always a good idea to have skilled employees, but even experts do make mistakes. After all, people that manually review code are only humans, which implies that the reviews are resource demanding, yet error prone. With the powerful tools of today's IDEs it is very easy to do refactoring hastily and soon the code starts to degrade. With a proper implementation, AspectJ offers one way to automate architectural enforcement, hereby preventing architectural drift.

Edit

2010-04-16: Added screenshot of AJDT plugin and an example of how the "set" pointcut can be used.

I was playing around with creating a Twitter clone, in my opinion the "Hello World" of graph databases, and I started out with the following simple service.

Spring configurating:

 
<beans ... >
	<context:annotation-config />
 
	<bean id="neo" class="org.neo4j.api.core.EmbeddedNeo"
		destroy-method="shutdown">
		<constructor-arg>
			<value>var/neo</value>
		</constructor-arg>
	</bean>
 
	<bean id="indexService" class="org.neo4j.util.index.NeoIndexService"
		destroy-method="shutdown">
		<constructor-arg ref="neo" />
	</bean>
 
	<bean id="twitterService"
		class="com.jayway.twitter.neo.NeoBasedTweetService">
<property name="neo" ref="neo" />
<property name="indexService" ref="indexService" />
	</bean>
 
	<!-- Transactions -->
	<tx:annotation-driven />
        ...
</beans>
 

The service:

 
public class NeoBasedTweetService implements TweetService {
 
	protected NeoService neo;
	protected IndexService indexService;
 
	//Setters for neo and indexService
 
	@Transactional
	public Tweet createTweet(User user, String tweet) {
		UserNode userNode = new UserNode(indexService.getSingleNode(
				TwitterIndexConstants.INDEX_USER, user.getUserName()));
		TweetNode tweetNode = new TweetNode(neo.createNode());
		tweetNode.setKvitt(tweet);
		userNode.createRelationshipTo(tweetNode, KvittRelationships.KVITTRAT);
		return tweetNode;
	}
 
	//Services to create User and more
 
}
 

This doesn't feel very DDD. I would really want to do the User to be responsible for creating the Tweet. Like this:

 
public class NeoBasedTweetService implements TweetService {
 
	protected NeoService neo;
	protected IndexService indexService;
 
	//Setters for neo and indexService
 
	@Transactional
	public Tweet createTweet(User user, String tweet) {
		UserNode userNode = new UserNode(indexService.getSingleNode(
				TwitterIndexConstants.INDEX_USER, user.getUserName()));
		return userNode.createTweet(tweet);
	}
 
	//Services to create User and more
 
}
 

The TweetNode and UserNode would look like this:

 
public class TweetNode extends NodeDelegate implements Tweet {
 
	TweetNode(Node underlyingNode) {
		super(underlyingNode);
	}
 
	//Methods for doing Tweet-stuff
 
}
 

 
public class UserNode extends NodeDelegate implements User{
 
	UserNode(Node underlyingNode) {
		super(underlyingNode);
	}
 
	//Methods for doing User-stuff
 
	public Tweet createTweet(String kvitt) {
		//Here comes a problem! I need a new Node
		//from the NeoService to create the TweetNode
		TweetNode tweetNode = new TweetNode(null);
		tweetNode.setTweet(tweet);
		createRelationshipTo(tweetNode, TwitterRelationships.TWEETED);
		return tweetNode;
	}
}
 

NodeDelegate, extended by both User- and TweetNode implements the Neo4j interface Node and delegates all the method calls to the underlying node ( for more on this, see my previous post) :

 
public class NodeDelegate implements Node {
 
	private Node delegate;
 
	protected NodeDelegate(Node underlyingNode) {
		delegate = underlyingNode;
	}
 
	//Methods for delegating all Node methods to the Node delegate
}
 

As you see I have a problem here. In the first version my NeoService is injected into NeoBasedTweetService and used when I create the new TweetNode. In the re-made, more DDD-style example I create the new TweetNode in the UserNode, where I don't have access to my NeoService. How do we solve this?

One alternative that I instinctively dislike is to inject the NeoService into the UserNode. The reason for me disliking this is that my UserNode IS a Node, and it feels very tangled if a Node holds a reference to its container. But I came to think of another solution thanks to a talk I did a while back together with Henrik Reinhold on what was new in Spring 2.5.

In Spring 2.5 load-time weaving (LTW) capabillites was introduced, and with LTW you can manipulate objects in load-time, as opposed to runtime weaving that is proxy based. This, combine it with @Configurable and @Autowired, proves to be very helpful when the Spring context is not in charge of creating the objects in question, as in the example above...

To enable LTW we add one tag in the Spring configuration:

 
<context:load-time-weaver />
 

After that we have to inform the Spring container of how we want thing done. To do we edit the TweetNode and NodeDelegate like this:

 
//Annotate the class with @Configurable so that Spring can find it.
@Configurable
public class TweetNode extends NodeDelegate implements Tweet {
 
	TweetNode(Node underlyingNode) {
		super(underlyingNode);
	}
 
	//Add a default constructor both in the TweetNode
	//and the NodeDelegate, it is new:able without a Node.
	public TweetNode() {
		super();
	}
 
	//Add a setter for the underlaying Node and annotate it with @Autowired.
	@Autowired
	public void setNode(Node nodeDelegate) {
		super.setNode(nodeDelegate);
	}
 
	//Tweet-methods as before
 
}
 

 
public class NodeDelegate implements Node {
 
	private Node delegate;
 
	protected NodeDelegate(Node underlyingNode) {
		delegate = underlyingNode;
	}
 
	protected NodeDelegate() {
	}
 
	protected void setNode(Node nodeDelegate) {
		if (delegate == null) {
			delegate = nodeDelegate;
		}
	}
 
	//Methods for delegating all Node methods to the Node delegate
 
}
 

Now Spring only has to be able to create Nodes. To do that we create a simple NodeFactory, like this:

 
public class NodeFactory implements FactoryBean{
 
	private NeoService neo = null;
 
	public void setNeo(NeoService neo) {
		this.neo = neo;
	}
 
	@Transactional
	public Object getObject() throws Exception {
		return neo.createNode();
	}
 
	public Class getObjectType() {
		return Node.class;
	}
 
	public boolean isSingleton() {
		return false;
	}
 
}
 

... and add it to the configuration, like this:

 
	<bean id="node" class="com.jayway.neo.utils.NodeFactory">
<property name="neo" ref="neo" />
	</bean>
 

The result of this is that Spring now has a NodeFactory that returns a new node for every request, I have annotated the TweetNode so that Spring knows of it (@Configurable) and what to do with it (@Autowired on setNode) and I've enabled load-time weaving in order to get the a new Node woven into a TweetNode every time a new instance of it is created in the code.

In UserNode I really don't have to make any changes. "setNode(Node)" will get a new Node after the instantiation of a TweetNode, even if the constructor that takes a Node is called. For clarity I still changed the UserNode as follows:

 
public class UserNode extends NodeDelegate implements User{
 
	UserNode(Node underlyingNode) {
		super(underlyingNode);
	}
 
	//Methods for doing User-stuff
 
	public Tweet createTweet(String kvitt) {
		//This TweetNode will get a Node set by Spring
		TweetNode tweetNode = new TweetNode();
		tweetNode.setTweet(tweet);
		createRelationshipTo(tweetNode, TwitterRelationships.TWEETED);
		return tweetNode;
	}
}
 

The problem I had when trying to make the UserNode responsible for creating its TweetNode's was that I needed to inject something that could create Nodes into the UserNodes. By using load-time weaving and instructing Spring of how to wire a TweetNode I don't have to pass my NeoService around to all the UserNodes created in my code. Instead I can rely on Spring to inject what is needed, when it's needed.

After searching on Google I found that there are two solutions for the problem which both includes an adapter class:

• Polling - The adapter class polls for changes in the POJO. While this solution is transparent to our POJOs it does not keep the state synchronised and is not very resource efficient.
• Observer-pattern - The adapter class listens for changes in the POJO. This implies that we add listener mechanism to our POJOs and thus not very transparent.

Michael Heinrichs at Sun have a great post about it. The problem is that none of these solutions are really adequate.

The best of both worlds

Since I didn't want to change my POJOs or coding adapters I had to come up with a new strategy. We've seen how listener mechanisms can be added using AOP. Great! By adding an aspect we can mixin the functionality we need for JavaFX to be able to bind to my POJOs. Furthermore we can generate the adapters. We only need to decide what fields we need to bind to in our POJOs. These will serve as our pointcuts. The default strategy would be to select all JavaBean properties. What a great day for coding a tool coding! The result is an easy to use tool that I hosted on Google Code:

http://code.google.com/p/javafxbinder/

For example if I have a POJO like this:

package se.jayway.javafxbinder.example.domain;
 
public class Person {
	private String name;
	private int age;
 
	public Person() {
	}
 
	public String getName() {
		return name;
	}
 
	public void setName(String name) {
		System.out.println("Name was set: " + name);
		this.name = name;
	}
 
	public int getAge() {
		return age;
	}
 
	public void setAge(int age) {
		this.age = age;
	}
}

Using JavaFX binder I can run the following command to generate some JavaFX code:

javafxbinder.sh -classpath ./target/classes -includes se.jayway.javafxbinder.example.domain.* -out ./output

And here is what gets generated:

package se.jayway.javafxbinder.example.domain;
 
import se.jayway.javafxbinder.example.domain.Person;
import se.jayway.javafxbinder.infrastructure.Bean;
import java.beans.PropertyChangeEvent;
import java.beans.PropertyChangeListener;
 
public class JfxPerson extends PropertyChangeListener {
    public-init var pojo : Person on replace oldValue {
        var oldBean : Bean = oldValue as Bean;
        oldBean.removePropertyChangeListener(this);
 
        var newBean : Bean = pojo as Bean;
        newBean.addPropertyChangeListener(this);
    };
 
    public var age : Integer = pojo.getAge() on replace {
        pojo.setAge(age);
    };
    public var name : String = pojo.getName() on replace {
        pojo.setName(name);
    };
 
    override public function propertyChange(event : PropertyChangeEvent) {
    	// Make sure that we're updating in the right thread
        FX.deferAction(function() {
            var bean : Bean = pojo as Bean;
            bean.removePropertyChangeListener(this);
            if (event.getPropertyName().equals("age")) {
                age = event.getNewValue() as Integer;
            }
            if (event.getPropertyName().equals("name")) {
                name = event.getNewValue() as String;
            }
            bean.addPropertyChangeListener(this);
        });
    }
}

To enable the listener functionality in my POJO I need to define an aspect:

package se.jayway.javafxbinder.example.domain;
 
import se.jayway.javafxbinder.infrastructure.Bean;
 
public aspect MyJavaBeans {
    declare parents: (se.jayway.javafxbinder.example.domain.Person) implements Bean;
}

Conclusion

Using AOP and a simple code generator is a good solution to the annoying JavaFX bind to Java problem. We use this tool for one of our clients and it works really good. However, my hope goes to someone at Sun/Oracle to integrate a similar functionality in the JavaFX compiler itself... Transparency looks good both in GUIs and in software design!

Simply replacing the original delegate will break the default functionality. We need to somehow insert our own code to execute before the original delegates call. Or in AOP speak; a before advice.

The Wanted Solution

What we want is a proxy that can forward invocations both to our own delegate, and to the original delegate. The interface for said class looks looks like this:

@protocol CWDelegateOverrideProxyDelegate
@required
-(BOOL)shouldCallOriginalImplementationForSelector:(SEL)aSelector;
@end
 
@interface CWDelegateOverrideProxy : NSProxy {
@private
  id<NSObject> _originalDelegate;
  id<NSObject> _overrideingDelegate;
  id<CWDelegateOverrideProxyDelegate> _delegate;
}
 
@property(nonatomic, retain, readonly) id<NSObject> originalDelegate;
@property(nonatomic, retain, readonly) id<NSObject> overridingDelegate;
@property(nonatomic, assign) id<CWDelegateOverrideProxyDelegate> delegate;
 
-(id)initWithOriginalDelegate:(id<NSObject>)originalDelegate
     overridingDelegate:(id<NSObject>)overridingDelegate;
 
@end

And then we could use this class to replace an existing delegate with a short piece fo code like this:

UITabBar* tabBar = (UITabBar*)[self.tabBarController.view
    viewWithKindOfClass:[UITabBar class]];
CWDelegateOverrideProxy* proxy = [[CWDelegateOverrideProxy alloc]
    initWithOriginalDelegate:tabBar.delegate overridingDelegate:self];
tabBar.delegate = (id<UITabBarDelegate>)proxy;

See my previous post for the implementation of viewWithKindOfClass:.

Easy enough to use, only thing left is to implement CWDelegateOverrideProxy.

Enter NSProxy

Java only have one root class; java.lang.Object. Objective-C can have many, and Cocoa defines two; NSObject and NSProxy. Both of them conforms to the protocol NSObject, wich can be confusing. What we need to know is that class names, and protocol names have two different name spaces in Objective-C. Imagine it as if you could have a class and an interface with the same name in Java; in Objective-C you can. NSObject class is the root class for all concrete classes, and NSProxy class is the root class for proxies, both implements NSObject protocol allowing them to be interchangeable.

Without much ado, here is the base implementation for the initializer:

#import "CWDelegateOverrideProxy.h"
 
@implementation CWDelegateOverrideProxy
 
@synthesize originalDelegate = _originalDelegate;
@synthesize overridingDelegate = _overridingDelegate;
@synthesize delegate = _delegate;
 
-(id)initWithOriginalDelegate:(id<NSObject>)originalDelegate
     overridingDelegate:(id<NSObject>)overridingDelegate;
{
  _originalDelegate = [originalDelegate retain];
  _overridingDelegate = [overridingDelegate retain];
  return self;
}
 
// More code goes here!
 
@end

Introspection

In Objective-C, just as in Java, an instance can be queried for its class, and conformance to protocols (interface in Java speak). But as a bonus an instance can also be queried for specific methods per instance.

Our CWDelegateOverrideProxy class inherits from NSProxy. And it makes a simple assumption; if the original delegate, or the overriding delegate is capable of something, then so it is. So if queried for type of class, protocol conformance, or implemented methods, then we reply with whatever our managed delegates replies.

The NSObject protocol defines methods, equivalent of the java.lang.reflect package, that allows us to implement this as such:

#pragma mark --- Testing Object Behavior, and Conformance
 
-(BOOL)isKindOfClass:(Class)aClass;
{
  return [self.overridingDelegate isKindOfClass:aClass] ||
         [self.originalDelegate isKindOfClass:aClass];
}
-(BOOL)conformsToProtocol:(Protocol *)aProtocol;
{
  return [self.overridingDelegate conformsToProtocol:aProtocol] ||
         [self.originalDelegate conformsToProtocol:aProtocol];
}
-(BOOL)respondsToSelector:(SEL)aSelector;
{
  return [self.overridingDelegate respondsToSelector:aSelector] ||
         [self.originalDelegate respondsToSelector:aSelector];
}

Invocation Forwarding

The NSObject protocol also defines methods for functionality equivalent of java.lang.reflect.InvocationHandler and hooks to act as a java.lang.reflect.Proxy. The details are different as Objective-C do not enforce calls to only known methods at compile time, which means that at run-time unimplemented methods can be called.

When an unimplemented method is called the run-time will call methodSignatureForSelector:, that can return a NSMethodSignature instance, sort of the equivalent of a java.lang.reflect.Method. The run-time will then use the information from the NSMethodSignature instance to create a correct NSInvocation (other half of a java.lang.reflect.Method) instance, and set the correct arguments. This NSInvocation instance is then used as argument to call forwardInvocation:.

And thus our implementation is completed with:

#pragma mark --- Handling Proxy Methods
 
-(NSMethodSignature*)methodSignatureForSelector:(SEL)aSelector;
{
  if ([self.overridingDelegate respondsToSelector:aSelector]) {
    return [self.overridingDelegate methodSignatureForSelector:aSelector];
  } else if ([self.originalDelegate respondsToSelector:aSelector]) {
    return [self.originalDelegate methodSignatureForSelector:aSelector];
  } else {
    return [super methodSignatureForSelector:aSelector];
  }
}
 
-(void)forwardInvocation:(NSInvocation*)anInvocation;
{
  BOOL shouldCallOriginal = YES;
  SEL aSelector = [anInvocation selector];
  if ([self.overridingDelegate respondsToSelector:aSelector]) {
    [anInvocation setTarget:self.overridingDelegate];
    [anInvocation invoke];
    if (self.delegate != nil) {
      shouldCallOriginal = [self.delegate shouldCallOriginalImplementationForSelector:aSelector];
    }
  }
  if (shouldCallOriginal && [self.originalDelegate respondsToSelector:aSelector]) {
    [anInvocation setTarget:self.originalDelegate];
    [anInvocation invoke];
  }
}

And that rounds up how to implement a class that handles proxy based AOP, in order to introduce a before advice for delegate methods. For a more complex code base you can look at HessianKit, a framework that uses proxies, invocation forwarding and dynamic class creation in order to use a web service as distributed objects.

Introduction

Aspect Oriented Programming (AOP) is gaining popularity within the Java SE/EE communities. There are many advantages of AOP especially as it provides a clear separation of concerns. The code becomes much more modular than with
traditional object technology. It’s not the intent of the article to explain all AOP
concepts and if you’re new to AOP you can find a couple of introduction sites in the
references section. Instead we will show how AOP can be used in CLDC enabled
devices such as mobile phones.
In Java ME applications there haven’t been much use of AOP. In fact, there
haven’t been any AOP frameworks available at all! Until now that is. AspectME
is a new open source project that delivers an AOP framework mainly targeted at
CLDC devices. Maybe most importantly, AspectME adds a reflection API. Reflec-
tion makes it possible to invoke methods and access fields dynamically. Advanced
frameworks use reflection to enable non-intrusive and modular mechanisms. Reflec-
tion is needed in AOP frameworks since we need information about where in the
code the aspect is executing.

What’s in the box?

AspectME consists of a runtime jar file that needs to be packaged together with
your Java ME application. Then we have an aspect weaver that is used to weave the
aspects into the compiled classfiles. During the weaving process necessary reflection
information is also added. What aspects to apply and extra reflection information is
controlled by a configuration file. And that’s all. To conclude, to use AspectME you’ll
need the following:

1. Add aspectmeruntime.jar to your Java ME project.
2. Write a configuration file that defines your aspects.
3. Run the aspect weaver after you’ve compiled your source code.

The assembly and deployment of your application is the same as before. AspectME
doesn’t change or remove debugging information so you can debug your application
as usual. Now, lets look at a small example.

Logging example

The first example is the classic logging example where we want to write enter/exit
outputs to the console around certain methods. Consider the following code:

public class Foo {
  public int bar(String s) {
    return Integer.intValue(s);
  }
}

It would be easy to add System.out statements when we enter and exit the method.
However, it would clutter the code, especially if we want to print out if we exit from
an exception:

public class Foo {
  public int bar(String s) {
    System.out.println(”Enter bar()”);
    try {
      int rv = Integer.intValue(s);
      System.out.println(”Exit bar()”);
      return rv;
    } catch (Exception e) {
      System.out.println(”Exit bar() from exception ” + e);
      throw new RuntimeException(e.getMessage());
    }
  }
}

Instead we can use AspectME and write an advice that can be used to weave logging
functionality into the code:

import org.aspectme.api.MethodInterceptor;
import org.aspectme.api.MethodInvocation;  

public class LoggingAdvice implements MethodInterceptor {
  public Object invoke(MethodInvocation mi) {
    // Create a pretty string
    String methodSignature = mi.getMethod().getName() + ”()”;  

    System.out.println(”Enter ” + methodSignature);  

    // Continue the method invocation
    Object rv = mi.proceed();  

    System.out.println(”Exit ” + methodSignature);
    return rv;
  }
} 

Now we need to define the pointcut where we want to apply the advice. In this case
it’s only one joinpoint, the bar() method, but we could apply the advice to many
joinpoints, e.g. all public methods in a package. AspectME uses the AspectJ pointcut
language because it’s powerful and de-facto standard within the AOP community.
We do this in a XML file:

 <?xml version=”1.0”?>
<aspectme>
  <pointcut id=”barMethod” expression=”execution(* org.aspectme.example.Foo.
bar())” />     

  <advice id=”log” class=”org.aspectme.example.aspects.LoggingAdvice” />  

  <aspect advice-ref=”log” type=”around” pointcut-ref=”barMethod” />
</aspectme>

Note that combining the parameters from the aspect definition actually describes
in “plain english” what the aspect does, “log around barMethod”. Now we’re ready
to weave everything together into the final executable. We do this with the weave
command from a shell:

weave -in classes -f aspectme.xml -out weaved_classes

The weave command will analyze all classes from the classes folder and weave in the
advices according to the definition in the aspectme.xml file. All modified classes will
be written to the weaved_classes folder.
But hey, didn’t we want to write to the console if we leave the method from an
exception? With AOP this becomes a breeze:

public class LoggingAdvice implements MethodInterceptor {
  public Object invoke(MethodInvocation mi) {
    // Create a pretty string
    String methodSignature = mi.getMethod().getName() + ”()”;  

    System.out.println(”Enter ” + methodSignature);  

    // Continue the method invocation
    try {
      Object rv = mi.proceed();  

      System.out.println(”Exit ” + methodSignature);
      return rv;
    } catch (Exception e) {
      System.out.println(”Exit ” + methodSignature + ” with exception ” + e);
      throw e;
    }
  }
} 

Note that we have totally separated the concern of logging in our example. We can
easily change the logging mechanism by editing a single file, even though it’s applied
in hundreds of joinpoints.

Persistence example

The previous example was simple but showed the basics of AspectME. Now lets
concentrate on a more interesting example. Imagine we have an application that will
manage contact information. If designed properly we would have a domain model
consisting of two classes, ContactList and Contact. The ContactList contains zero or
more Contact objects.
The MIDlet would create the ContactList at startup and pass the model to the views.
The views would use the ContactList to add and remove Contact elements. In tradition-
al application design we would add a ContactListDAO that manages the persistence mechanism. The DAO object would be used from the controller whenever a contact is added or removed. Nice design? Not really since the DAO clutters the code and adds unnecessary infrastructure code into our application.
Using the AOP approach we would intercept the execution at certain joinpoints
as shown in the picture. We start by writing a persistence advice:

public class PersistenceAdvice implements MethodInterceptor,
                                          ConstructorInterceptor {  

  /**
   * Stores the target object after invocation.
   * @param invocation The joinpoint of the method invocation.
   * @return The return value from the method invocation.
   */
  public Object invoke(MethodInvocation invocation) throws Throwable {
    // Run the target method
    Object result = invocation.proceed();  

    // Store the object
    store(invocation.getThis());  

    // Return the result
    return result;
  }  

  /**
   * Loads an object from the record store instead of creating it.
   * @param invocation The joinpoint of the constructor call.
   * @return The created object.
   */
  public Object construct(ConstructorInvocation invocation) throws Throwable
{
    Object obj = load();
    // If this is the first time we load the object we’ll get a null object.
    // In that case we need to create the object, i.e. proceed with the
    // normal execution.
    if (obj == null) {
      obj = invocation.proceed();
    }
    return obj;
  }  

  private void store(Object obj) throws IOException {
    // Store the passed object into the record store by serializing it
    // to the record store
  }  

  private Object load() throws IOException {
    Object obj = null;
    // Load the specified object from the record store
    return obj;
  }
}

The advice implements both the MethodInterceptor and ConstructorInterceptor.
The MethodInterceptor is used to intercept methods that changes the object and
store them in the record store. In our case the ContactList. The ConstructorIn-
terceptor is used to intercept the creation of ContactList objects, so rather than
creating them it will load them from the record store. This means that anywhere in
the code we execute “new ContactList()” we would load the object and return the
loaded object instead of creating it.
The serialization of objects can be made using the reflection API in AspectME.
An ObjectOutputStream reads the field values from the written object and primi-
tive fields are written to the DataOutputStream. Objects are written recursively.
Counterwise we have an ObjectInputStream that reads objects by writing the field
values by reading them from a DataInputStream. The result is very similar to Java
SE serialization mechanism as shown in the code example below.

public Object storeAndLoad(Object obj) {
  // Write object to byte array
  ByteArrayOutputStream byteOut = new ByteArrayOutputStream();
  ObjectOutputStream objOut = new ObjectOutputStream(byteOut);
  objOut.writeObject(obj);
  objOut.close();
  byteOut.close();
  byte[] bytes = byteOut.toByteArray();  

  // Read object from the byte array
  ByteArrayInputStream byteIn = new ByteArrayInputStream(bytes);
  ObjectInputStream objIn = new ObjectInputStream(byteIn);
  return objIn.readObject();
}

If you’re interested in the implementation of the classes you can find them in the
code examples on the AspectME home page (see References).
All that’s left is to define our aspects in an aspectme.xml file:

<?xml version=”1.0”?>
<aspectme>
   <pointcut id=”addRemoveMethods”
             expression=”execution(*
*..domain.ContactList.addContact(..)) ||
                         execution(*
*..domain.ContactList.removeContact(..))” />
   <pointcut id=”newContactList”
expression=”call(*..domain.ContactList.new())” />
   <advice id=”persist”
class=”org.aspectme.example.aspects.PersistenceAdvice” />
   <aspect advice-ref=”persist” type=”around”
pointcut-ref=”addRemoveMethods” />
   <aspect advice-ref=”persist” type=”around”
pointcut-ref=”newContactList” />
   <!-- This will add reflection information for all objects
in the specified package. -->
   <reflect include=”org.aspectme.example.contact.domain.*” />
</aspectme>

After the weaving process our application will store the ContactList object into the
record store whenever a contact is added or removed. When the application is run
again the ContactList object is loaded from the record store. The application can
still run without the persistence aspect but all contact information will be lost when
the application closes. A good example of how crosscutting concerns creates total
transparency of an application mechanism.

Summary

AspectME is a promising AOP framework that can be used to take advantage of
AOP in CLDC enabled devices. The reflection capabilities add new dimensions to
CLDC applications such as object serialization. We have seen how advices can be
built and reused over many applications since it crosscuts the concern of persist-
ence. The performance impact is acceptable when dealing with large concerns such
as persistence. The bytecode footprint increases a couple of KB but that is a small
price to pay for the increased modularity. Often the footprint becomes smaller as we
gather all copy’n’paste like infrastructure code into small advices.

Originally published in JayView.

 
public class StupidSingleton {
	public static String doStatic(int i) {
		throw new UnsupportedOperationException("method not implemented yet...");
	}
 
	public static void sayHello() {
		System.out.println("Hello");
	}
 
	public static native void nativeMethod();
}
 

We would like to write something like this:

 
	public void testMocking() {
		mock(StupidSingleton.class);
		expect(StupidSingleton.doStatic(17)).andReturn("17");
		StupidSingleton.sayHello();
		StupidSingleton.nativeMethod();
		replay(StupidSingleton.class);
 
		assertEquals("17", StupidSingleton.doStatic(17));
		StupidSingleton.sayHello();
		StupidSingleton.nativeMethod();
 
		verify(StupidSingleton.class);
	}
 

After playing around with AspectJ I discovered that this is actually possible! Two things are needed:
* An aspect that allows us to catch calls to static methods!
* An implementation of the mock, replay, verify for classes

This turns out to be really easy! The following aspect catches ALL calls to ALL static methods. Might be a bit aggressive, but it works! If you want you can implement your own aspect with a more specialized pointcut.

 
@Aspect
public class StaticMockAll extends StaticMockAspect {
	@Pointcut("call(static * *(..))")
	public void anyStaticOperation() {}
 
	@Around("anyStaticOperation()")
	public Object aroundStaticMethods(ProceedingJoinPoint jp) throws Throwable {
		return super.aroundStaticMethods(jp);
	}
 
}
 

The mock, replay, verify methods turns out to be trivial:

 
public class StaticMock {
	static Map<Class, MockInvocationHandler> mocks = new HashMap<Class, MockInvocationHandler>();
 
	public static synchronized void mock(Class type) {
		MockInvocationHandler h = new MockInvocationHandler((MocksControl) EasyMock.createControl());
		mocks.put(type, h);
	}
 
	public static synchronized void replay(Class type) {
		mocks.get(type).getControl().replay();
	}
 
	public static synchronized void verify(Class type) {
		mocks.remove(type).getControl().verify();
	}
}
 

Finally, the base class for the aspect that does the actual work is also quite simple:

 
public class StaticMockAspect {
	public Object aroundStaticMethods(ProceedingJoinPoint jp) throws Throwable {
		Class type = jp.getSignature().getDeclaringType();
		InvocationHandler h = getInvocationHandler(type);
		if (h == null) {
			return jp.proceed();
		}
		MethodSignature methodSignature = ((MethodSignature)jp.getSignature());
		return h.invoke(type, methodSignature.getMethod(), jp.getArgs());
	}
 
	private MockInvocationHandler getInvocationHandler(Class type) {
		synchronized (StaticMock.class) {
			return StaticMock.mocks.get(type);
		}
	}
 
}
 

h3. Notes

Things to note and think about:
* Static methods and native methods can be mocked! By using the "call" pointcut we change all code that tries to call the native methods and not the native method itself.
* AspectJ is required to make this work. I have been using Eclipse AJDT
* It should be possible to replace the Aspect with "plain" byte code manipulation and "just" reload the class.

Entering [org.springframework.ldap.LdapTemplateListTest.]
Exiting [org.springframework.ldap.LdapTemplateListTest.]
Entering [org.springframework.ldap.LdapTemplateListTest.setUp]
  Entering [org.springframework.ldap.LdapTemplate.]
    Entering [org.springframework.ldap.DefaultNamingExceptionTranslator.]
    Exiting [org.springframework.ldap.DefaultNamingExceptionTranslator.]
  Exiting [org.springframework.ldap.LdapTemplate.]
  Entering [org.springframework.ldap.LdapTemplate.setExceptionTranslator]
  Exiting [org.springframework.ldap.LdapTemplate.setExceptionTranslator]
Exiting [org.springframework.ldap.LdapTemplateListTest.setUp]
Entering [org.springframework.ldap.LdapTemplateListTest.testList_Name]
  Entering [org.springframework.ldap.LdapTemplateListTest.expectGetReadOnlyContext]
  ...

The part that keeps track of the indentation level was written as a reusable aspect:

package org.springframework.ldap.aspects; 
 
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
import org.aspectj.lang.JoinPoint; 
 
/**
 * Abstract logging aspect for producing indented logging. Override the
 * <code>loggingOperations</code> pointcut in order to provide the joinpoints
 * where you would like the logging to be applied. Also override the methods
 * <code>beforeLog</code> and <code>afterLog</code> to provide the actual
 * logging statements. The current indentation string will be provided to these
 * methods, along with an instance of <code>JoinPoint</code>.
 *
 * @author Ulrik Sandberg
 */
public abstract aspect IndentedLogging {
    Log log = LogFactory.getLog("trace"); 
 
    /**
     * The current number of indentation levels.
     */
    protected int indentationlevel = 0; 
 
    /**
     * Override and provide pointcut to log.
     */
    protected abstract pointcut loggingOperations(); 
 
    /**
     * Override and provide the actual logging statement for when the logged
     * method is entered.
     *
     * @param indent
     *            The string of spaces that provides the current indentation.
     * @param joinPoint
     *            Information about the current joinpoint.
     */
    protected abstract void beforeLog(String indent, JoinPoint joinPoint); 
 
    /**
     * Override and provide the actual logging statement for when the logged
     * method is exited.
     *
     * @param indent
     *            The string of spaces that provides the current indentation.
     * @param joinPoint
     *            Information about the current joinpoint.
     */
    protected abstract void afterLog(String indent, JoinPoint joinPoint); 
 
    Object around(): loggingOperations() {
        StringBuffer sb = new StringBuffer();
        if (log.isInfoEnabled()) {
            indentationlevel++;
            for (int i = 0, spaces = indentationlevel * 2; i &lt; spaces; i++) {
                sb.append(" ");
            }
            beforeLog(sb.toString(), thisJoinPoint);
        }
        Object result;
        try {
            result = proceed();
        } finally {
            if (log.isInfoEnabled()) {
                afterLog(sb.toString(), thisJoinPoint);
                indentationlevel--;
            }
        }
        return result;
    }
}

Since the reusable aspect does all the grunt work, the actual tracing aspect becomes rather small:

package org.springframework.ldap.aspects; 
 
import org.aspectj.lang.JoinPoint; 
 
public aspect TraceAspect extends IndentedLogging {
    declare precedence: TraceAspect, *; 
 
    protected pointcut loggingOperations():
        (execution(* *.*(..)) || execution(*.new(..)))
        && !within(IndentedLogging+); 
 
    protected void beforeLog(String indent, JoinPoint joinPoint) {
        log.info(indent + "Entering ["
                + joinPoint.getSignature().getDeclaringTypeName() + "."
                + joinPoint.getSignature().getName() + "]");
    } 
 
    protected void afterLog(String indent, JoinPoint joinPoint) {
        log.info(indent + "Exiting ["
                + joinPoint.getSignature().getDeclaringTypeName() + "."
                + joinPoint.getSignature().getName() + "]");
    }
}

Now, let's say we don't want to trace each and every method and constructor execution, but rather a small subset, like for example only the normal methods (no constructors) in any subclass of NameClassPairCallbackHandler. We'll remove the execution of new from the pointcut and add the handler subclass condition:

public aspect TraceAspect extends IndentedLogging {
    declare precedence: TraceAspect, *; 
 
    protected pointcut loggingOperations():
        execution(* *.*(..)) // just plain methods
        && !within(IndentedLogging+)
        && within(org.springframework.ldap.NameClassPairCallbackHandler+); // added
    ...

The output becomes:

Entering [org.springframework.ldap.CollectingNameClassPairCallbackHandler.handleNameClassPair]
  Entering [org.springframework.ldap.LdapTemplate$MappingCollectingNameClassPairCallbackHandler.getObjectFromNameClassPair]
  Exiting [org.springframework.ldap.LdapTemplate$MappingCollectingNameClassPairCallbackHandler.getObjectFromNameClassPair]
Exiting [org.springframework.ldap.CollectingNameClassPairCallbackHandler.handleNameClassPair]
Entering [org.springframework.ldap.CollectingNameClassPairCallbackHandler.getList]
Exiting [org.springframework.ldap.CollectingNameClassPairCallbackHandler.getList]

You might argue that it would be good to see the arguments to each call. That could easily be done by using JoinPoint.getArgs() in the tracing aspect. It would look like this:

package org.springframework.ldap.aspects; 
 
import org.aspectj.lang.JoinPoint; 
 
public aspect TraceAspect extends IndentedLogging {
    declare precedence: TraceAspect, *; 
 
    protected pointcut loggingOperations():
        (execution(* *.*(..)))
        && !within(IndentedLogging+)
        && within(*..NameClassPairCallbackHandler+); 
 
    protected void beforeLog(String indent, JoinPoint joinPoint) {
        log.info(indent + "Entering ["
                + joinPoint.getSignature().getDeclaringTypeName() + "."
                + joinPoint.getSignature().getName()
                + createParameterMessage(indent, joinPoint) + "]");
    } 
 
    protected void afterLog(String indent, JoinPoint joinPoint) {
        log.info(indent + "Exiting ["
                + joinPoint.getSignature().getDeclaringTypeName() + "."
                + joinPoint.getSignature().getName()
                + createParameterMessage(indent, joinPoint) + "]");
    } 
 
    private String createParameterMessage(String indent, JoinPoint joinPoint) {
        StringBuffer sb = new StringBuffer("(");
        Object[] args = joinPoint.getArgs();
        if (args.length > 0) {
            sb.append("\n    " + indent);
        }
        for (int i = 0; i < args.length; i++) {
            sb.append(args[i]);
            if (i != args.length - 1) {
                sb.append(',');
            }
        }
        sb.append(")");
        return sb.toString();
    }
}

And the output would be this:

Entering [org.springframework.ldap.CollectingNameClassPairCallbackHandler.handleNameClassPair(
    o=example.com: com.example.SomeClass)]
  Entering [org.springframework.ldap.LdapTemplate$MappingCollectingNameClassPairCallbackHandler.getObjectFromNameClassPair(
      o=example.com: com.example.SomeClass)]
  Exiting [org.springframework.ldap.LdapTemplate$MappingCollectingNameClassPairCallbackHandler.getObjectFromNameClassPair(
      o=example.com: com.example.SomeClass)]
Exiting [org.springframework.ldap.CollectingNameClassPairCallbackHandler.handleNameClassPair(
    o=example.com: com.example.SomeClass)]
Entering [org.springframework.ldap.CollectingNameClassPairCallbackHandler.getList()]
Exiting [org.springframework.ldap.CollectingNameClassPairCallbackHandler.getList()]

Trots att vi anstränger oss till det yttersta att modellera våra system intill perfektion, nåja i alla fall väldigt, väldigt nära, så är det fortfarande svårt att fånga strukturen hos ett problemområde. Detta märks t ex genom att vi kopierar välbehövliga små bitar kod och lägger in dem överallt. Inte nog med detta, de klasser som helst bara skulle behöva lösa en uppgift, tvingas att känna till säkerhet, databas, loggning osv. Allt detta leder till system som är svåra att underhålla och förändra.

Vad skulle hända om vi kunde plocka ut all loggning i våra projekt och lägga dem i en separat klass – en aspekt? Istället för att sprida ut en viss lösning i vårt system, kan vi nu underhålla den på ett enda ställe. När programmet kompileras så förs koden tillbaks ut där vi hade den innan.

För att bättre förstå vad aspekter är tittar vi närmare på AspectJ, som är en variant av AOP baserad på öppen källkod. Den har flera år på nacken och skapades på Xerox PARC som ett forskningsprojekt med stöd av DARPA.

Ett exempel: Var finns egentligen koden för loggning?

Kodpunkt, punktsnitt och direktiv

I aspektorienterad programmering kan man samla alla dessa små bitar kod på ett enda ställe. Men vi måste ju fortfarande kunna köra dessa på givna ställlen i programmet? Lösningen i AspectJ är att identifiera punkter i exekveringen av ett program – så kalllade kodpunkter (joinpoints).
Det finns flera olika typer av kodpunkter man kan identifiera; metodanrop, skapande av objekt, att sätta attribut, utlösning av undantag (exceptions) osv. Ett punktsnitt samlar en omgång kodpunkter och ger dem ett namn.
Genom att ange kod, direktiv (advice), som ska köras vid dessa kodpunkter kan vi samla tvärgående intressen (crosscutting concerns) i en enda fil – en aspekt. Eller annorlunda uttryckt:

aspekt = punktsnitt(kodpunkter) + direktiv

En aspekt består av en omgång identifierbara punkter i programmet där extra kod ska köras.

Vad kan man göra mer?

Vi har bara gått igenom ett hyfsat enkelt exempel till höger, men det finns många saker man kan använda AspectJ:

• Olika former av loggning och debugging.
• Design-by-contract, d v s att man kollar inoch utgående tillstånd och parametrar. När man är nöjd att systemet uppfyller kraven kan man ta bort dessa aspekter.
• Testa optimering, alternativa lösningar etc.
• Cachning, synkronisering, accesskontroll etc.
• ... och fler tekniska aspekter som inte har med vårt problemområde att göra.

Innan har vi endast talat om dynamisk förändring av ett program, d v s att påverka arbetsflödet. Men det går också att ändra den statiska strukturen genom att lägga till t ex klassvariabler, metoder, ändra arv. Här uppstår fler möjligheter:

• Multipelt arv som t ex mix-in i C++
• Genomförande av kodstandard. ”Ingen får ändra en variabel direkt”. Denna koll kan t o m göras vid kompilering!

Listan kan göras mycket längre. Vi befinner oss bara i början av vår förståelse om var och hur vi bäst använder aspektorienterad programmering. Även om denna inte kommer att ersätta objektorienterad programmering (OOP) så kommer den att vara grunden för AOP på samma sätt som funktioner utgör grunden för OOP.

Ett enkelt (nåja) exempel

Vi skulle kunna gå igenom ett enkelt ”Hello Aspect World”, men jag väljer iställlet att dyka i lite djupare. Jag vill mäta hur lång tid det tar att anropa databasen i vårt hemmasnickrade modelllager.
Vår modellkod innehålller en abstrakt klass som definierar ett gränssnitt för att arbeta mot databasen. Personklassen representerar en post i person-tabellen och implementerar själva anropen med SQL mot databasen i metoderna dbSave, dbUpdate och dbRemove. I ett anfall av hybris lägger jag in mig själv i databasen. Demokod:

Vårt enkla modell-lager som kapslar in databasen.

DBObject tPerson = new Person();
tPerson.setField("firstName", "Björn");
tPerson.setField("lastName", "Granvik");
tPerson.dbSave();

tPerson.setField("company", "Jayway");
 tPerson.dbUpdate();

Du gamla vanliga lösning

Låt oss nu göra en enkel tidtagning. På det gamla sättet så blir det till att kopieraoch-klistra, så mycket som vi nu orkar. Till exempel skulle Person.dbSave kunna se ut som följer:

void dbSave() {
    long tTime = System.currentTimeMillis();
    // Do something...
    tTime = System.currentTimeMillis() tTime;
    System.out.println( thisJoinPoint + ": " + tTime );
}

Och på samma sätt för de andra metoderna dbUpdate och dbRemove. Även om vi förbättrar situationen genom att introducera en tidtagningsklass blir det bara marginellt bättre – det är fortfarande korkad kod! Dessutom så kommer den att ta tid att exekvera. Inget vi vill ha kvar i en produktionsversion.

Du sköna nya aspekt

Låt oss titta på hur man skulle kunna lösa problemet med hjälp av aspekter. Vår nya lösning innehåller en del nya ord som tillägg till Java-språket, se fetstil nedan, men är inte så svår som det först verkar.

/* A timing aspect on DBObject.db methods */
public aspect DbTimerAspect {

    /* Public DBObject methods starting with 'db',
     * taking no parameters and returning anything. */
    pointcut dbMethods() : execution( public * DBObject.db*());

    /* A simple timer advice to be called instead
     * of the original method. */
    void around() : dbMethods() {
        long tTime = System.currentTimeMillis();
        proceed();    // Proceed with call to DbObject.
        tTime = System.currentTimeMillis() tTime;
        System.out.println( thisJoinPoint + ": " + tTime );
    }
}

Vår aspekt DbTimerAspect innehåller dels de metoder som vi vill mäta och den tidmätare vi vill ska köras.
I kodsnittet dbMethods (pointcut) väljs de publika metoder i DBObject och dess subklasser som börjar på ”db”. Vi anger också att det är när metoden körs (execution) som är intressant. Här kan man välja på fler varianter; när metoden anropas, när ett attribut ändras, när ett objekt skapas och många fler sorters kodpunkter.

När demokoden anropar Person.dbSave så är det vårt direktiv som körs istället. Nyckelordet som anger detta är around. Vi hade naturligtvis kunnat ange att den skulle köras före, efter osv. Det första vi gör är att ta reda på tiden. I nästa steg anropar vi originalmetoden med ”proceed”. Nu körs Person.dbSave som vanligt.

Efter att vi kommer tillbaka räknar vi ut den tid som tillbringats i anropet och skriver ut den på konsolen. Lägg märke till att vi har tillgång till den kodpunkt som vi befinner oss i m h a thisJoinPoint. Resultat
När vi kompilerar vår kod gör vi det med kompilatorn från AspectJ. Den genererar ren Java ”byte code”, dvs. koden kan köras precis som vanligt.

Resultatet på konsolen blir:

execution(void se.jayway.jayview.aop.Person.dbSave()): 111
execution(void se.jayway.jayview.aop.Person.dbUpdate()): 30

Ganska mycket det vi förväntade oss.

Slutkläm

Denna artikel räcker egentligen inte för att förstå hela vidden av det man kan göra med aspekter. Jämför vi med en vinprovning har vi bara hunnit titta på etiketten. Men, likväl, vårt lilla exempel pekar på de stora möjligheter som finns med aspekter.
När och var bör man då använda AOP? Än så länge är aspekter inte ”bevisade”. Hur kommer de att skala? Hur påverkas arkitekturen i skarpt läge etc?
Däremot så är det mycket intresssant att förbättra hur vi utvecklar dessa system. Mitt råd blir därför; Skapa aspekter som stödjer din kodstandard, testar varianter av din lösning utan att behöva modifiera koden, gör verktyg som t ex loggningsaspekter, etc.
Om jag ska våga mig på en gissning tror jag att vi inom några år kommer att ha sådana ”tekniska” aspekter som öppen källkod. Fast jag kan ha fel – de kommer kanske redan om ett år eller så

Termer

kodpunkt (joinpoint) En punkt i exekveringen av ett program, till exempel i anropet av en metod i en klass.
punktsnitt (pointcut) En samling utvalda kodpunkter.
direktiv (advice) Kod som körs vid utvalt punktsnitt under angivna omständigheter, t ex kan man logga ett anrop innan det körs.
tvärgående intressen (crosscutting concerns) Ett system har oftast flera mål som det försöker uppfylla. Förutom att lösa grundproblemet (t ex lönehantering) så finns där också uppgifter som t ex loggning, säkerhet etc. Dessa uppgifter, eller intressen, är typiskt utspridda i systemet – de går på tvären genom strukturen.
OOP Objektorienterad programmering en programmeringsteknik och synsätt som gör det möjligt att öka komplexitetsgrad och återanvändning.
AOP Aspektorienterad programmering att göra fristående moduler som hanterar tvärgående intressen på ett sådant sätt att de kan sömlöst kan föras in i koden igen vid t ex kompilering.

Resurser
AspectJ
Eclipse, AspectJ plug in
JavaWorld: I want my AOP!
AOSD – Aspect Oriented Software Development

Originally published in JayView.