Part I: Why Use Aspect-Oriented Technologies?

Adding Persistence

public class User {
  private String userName;
  private String password;
  private String firstName;
  private String lastName;
  private String email;
  private Address address;

  public String getUserName() {
    return userName;
  }

  public void setUserName(String userName) {
    this.userName = userName;
  }

  public String getPassword() {
    return password;
  }

  public void setPassword(String password) {
    this.password = password;
  }

  ...etc.
}

						
boolean dirty = false;

  ...

  public String getUserName() {
    return userName;
  }

  public void setUserName(String userName) {
    this.userName = userName;
    dirty = true;
  }

  public String getPassword() {
    return password;
  }

  public void setPassword(String password) {
    this.password = password;
    dirty = true;
  }
  ...

  if (dirty) {
    // save to database
    dirty = false;
  }

Using Aspects

aspect Persistence {

  Set dirtyObjects = new HashSet();
  // let's assume the action classes are in a package called auction 
  pointcut dirty(DomainObject o):
    target(o) && call(* auction..*.set*(..));

  after(DomainObject o) returning: dirty(o) {
  	dirtyObjects.add(o);
  	// note that the following is over simplified and NOT safe
  	if (dirtyObjects.size() > MAXDIRTY) {
  	   // write dirty objects to database
  	   dirtyObjects.clear();
  	}
  }
}

• aspect - you must name your aspect. You can loosely treat an aspect like a class (more on this later).
• join points - places in a runtime cycle where "something happens", or something gets executed. e.g. in Java:
• method calls
• method executions (differentiated because of polymorphism)
• instantiations
• field references
• exceptions thrown, etc.
• pointcut - picks out these join points. Pointcuts and advice (explained further down) have the following parts:
• target - which instances are you concerned with? e.g. here, we're interested in DomainObject instances
• && - "and". "Or" is represented with ||
• call - example of a "designator", i.e. in this case when a method is called
• * - wildcard, matches return types, method names
• .. - wildcard for method argument list or different levels of a package structure
• advice - defines pieces of implementation that execute at particular join points picked out by a pointcut. Different types of advice include:
• before - this runs just before the execution of actions associated with events in a pointcut
• after - this runs just after
• returning - this also runs after, but only if it returns normally.
• throwing - this also runs after, but only if it throws an exception, e.g.
  after() throwing(Exception e): ...

  Set dirtyObjects = new HashSet();
  // let's assume the action classes are in a package called auction 
  pointcut dirty(DomainObject o):
    target(o) && call(* auction..*.set*(..));

  after(DomainObject o) returning: dirty(o) {
  	dirtyObjects.add(o);
  	// note that the following is over simplified and NOT safe
  	if (dirtyObjects.size() > MAXDIRTY) {
  	   // write dirty objects to database
  	   dirtyObjects.clear();
  	}
  }

Tools

packages
|-ClassName.java
  |-method()
    |-advisers

packages
|-AspectName.java
  |-pointcut
  |-after
  |-afterReturning

Applications

• Development/testing aspects, e.g. for debugging, logging problems. You'll use these, then throw them away.
• Production aspects, e.g. security, transactions. You'll keep these.

• Session tracking
• Any time you're passing something around all over, just because someone somewhere down the line might need it. e.g. EJB context
• Frank also suspects this does away with double dispatching and the visitor pattern (I've detested both for years)

• When you realize you have a crosscutting concern with similar functionality throughout
• There's a whole discussion on this in a tutorial, will cover later

• they can be in packages
• they can be inner classes/aspects (??!!)
• they can be extended (and implement??)

• you can't instantiate aspects using new, they are instantiated automatically when join points are hit (that's another question, are they really instantiated or is AspectJ more like a precompiler which stuffs code into methods, then compiles them??)
• by default aspects are singletons...

• Aspects can actually add fields to objects, and this gets done at compile time.
• Aspects can inherit from each other. We're going to see a whole new catalog of design patterns that spring up around AOP.

Implications of AOP

Past, Present, Future

• users@aspectj.org
• support@aspectj.org

References