Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [aspectj-users] Patterns of pointcuts
An alternative would be to use the "participant pattern", where you define an abstract pointcut in an abstract base aspect and (in your case) each package participates in the collaboration offered by the base aspect by creating a concrete subaspect and providing the definition for the abstract pointcut. 

For example, your base aspect might look like the following:

public abstract aspect BaseSomething {
   public abstract pointcut something();

  before() : something() {
      ...
  }
}

the package1 would participate by writing a subaspect as follows:
package package1;

public aspect ConcreteSomething extends BaseSomething {
   public pointcut something() :  ... // equivalent of your p1() pointcut
}

Each package defines a subaspect in an identical manner.
The participant pattern is a more general mechanism, where you can also use abstract methods that collaborate with the aspect in a per-participant manner. For example, the base aspect could include an abstract method, invokes it from advice, allowing each participants to provide specific behavior by implementing that method.
See http://www.ibm.com/developerworks/java/library/j-aopwork3/ for one usage of this pattern. <plug>Of course, AspectJ in Action contain more examples of this pattern.</plug> 

-Ramnivas

===
Ramnivas Laddad,
Author, AspectJ in Action
http://ramnivas.com
M: (408)203-4621

Nathan McEachen wrote:
My understanding is that if I want to define a pointcut in terms of other pointcuts, I need to enumerate them: 

   pointcut somepointcut() : p1() || p2() || p3();
I am thinking it would be nice to define a pointcut in terms of other pointcuts by using a pattern (I am pretty sure you cannot do this) Example: 

   pointcut somepointcut() : p*();

Here is my rationale:
I am envisioning a large project with many teams of developers. Each team defines a pointcut to represent a given semantic event (e.g. a transaction) as implemented in their respective modules. p1() captures join points for semantic event E as implemented in package1 by team 1 p2() captures join points for semantic event E as implemented in package2 by team 2 p3() captures join points for semantic event E as implemented in package3 by team 3 
   etc..
Each team does not know the implementation details of event E in the other packages. In a large project, the cognitive burden of the implementation details of event E across the entire project may prove too great for a single person.
In order to weave advice for event E across the entire project, such advice would have to reference some pointcut pg() (g for global) that included p1(), p2(), and p3(): 

   pointcut pg() : p1() || p2() || p3();
So far so good. But what if a 4th package were added to the project written by a 4th team? An additional pointcut, p4() would need to be created, plus pointcut pg() would need to be updated to include it.
Wouldn't it be nice if we could add additional such packages and not have to maintain the definition of pg()? 

   pointcut pg() : p*();
Is there a way to define a pointcut in terms of other pointcuts without explicitly enumerating them? If not, then do you agree/disagree with the usefulness of having such a feature? 


Thanks in advance for your thoughts,

-Nathan

Back to the top