subaspect

In this iteration I'm going to modify each method to have an annotation and go back to one subaspect for the system (as in Version 2).

Instead of a large N, I've reduced the system coupling to a smaller number of program elements captured by each subaspect, say n-to-1.

They rely on a pointcut rather than a type, either assuming nothing or deferring a context specification to a concrete subaspect.

While it's an improvement, this design still leaves us with an N-to-1 dependency between the subaspect and classes.

However, separating the base aspect from the metadata-driven subaspect has a few advantages.

Listing 5 shows a metadata-drive subaspect of the ReadWriteLockSynchronizationAspect aspect for a banking system.

The subaspect below defines a pointcut that captures the join points needing transaction management support.

Class with a participant subaspect that is responsible for defining the pointcut for the embedded class.

The subaspect itself will be reusable across systems.

Now if a class changes, I need to modify only the nested subaspect in that class.

Listing 3 shows a banking-specific subaspect that extends the TxMgmt aspect in Listing 2.

Next, I need to write a subaspect for my base aspect.