1. Aspect-Oriented Design and Patterns
Ilja Livenson
University of Tartu

2. Overview
Introduction
Patterns
Idioms
Links

3. AOP Design Patterns and Idioms (1)
Design patterns and idioms define solutions to recurring design issues
Patterns are language independent
Idioms are language dependent
Basically, one can divide AO patterns into two types:
Pure AO patterns (today’s topic)
OO patterns with applied aspects (next week’s topic)
The difference between design patterns and idioms involves the scope at
which they solve problems and their language specificity. From the scope point
of view, idioms are just smaller patterns. From the language point of view, idioms
apply to a specific language whereas the design patterns apply to multiple languages
using the same methodology. Only a few languages currently support
AOP. Therefore, at this point, the differences between patterns and idioms from
the AOP perspective are mostly based on their scope and complexity. Some years
from now, when we may have a significant number of languages supporting the
AOP paradigm, we will be able to make a better differentiation. The patterns we
examine in this chapter are so powerful that any emerging languages will likely
support them, thus making them language-independent.

4. AOP Design Patterns and Idioms (2)
Today we shall examine 4 patterns
The worker object creation pattern
The wormhole pattern
The exception introduction pattern
The participant pattern

5. AOP Design Patterns and Idioms (3)
Avoiding infinite recursion
Nullifying advice
Providing empty pointcut definitions
Providing a default interface implementation
Restricting SQL calls
Matching sub-classes

6. The Worker Object Creation Pattern (WOC)
Used when you need to route each direct call to a specific set of methods through a worker object
A worker object is an instance of a class that encapsulates a method (called a worker method) so that the method can be treated like an object
The worker object creation pattern offers a way to capture operations with a pointcut and automatically generate worker objects that encapsulate those operations.
Sample applications:
Swing UI updates (wrapping UI updates in a Runnable wrapper)

7. WOC - Before
Implement a class that will route the method and create an object of that class.
Use that object instead of the method that was originally called.
Depending on the situation, you may use either named or anonymous classes. In
either case, you implement an interface such as Runnable that contains a run()
method for calling the operation. If you use named classes, you must add a constructor
to accept all the arguments that will be passed to the operation. If you use
anonymous classes, you don’t (and can’t) write a constructor. Instead, you create the
class locally and pass the variables from the outer context (where the class is implemented)
as arguments to the method called in the run() method. You should mark
each local variable passed as final to comply with Java’s requirement on local classes.
With either style, you need to replace the normal method call with the creation
of a worker object (step 1) and invoke the object (step 2). The sheer amount of
code makes implementation a daunting task; it also increases the risk of missing
certain changes, which may result in undesired system behavior. For example, if
you do not reroute certain calls to Swing components that originate in threads
other than the event-dispatching thread, you may observe hard-to-explain UI
anomalies or even crashes.

8. WOC - After
Write a pointcut capturing all the join points that need routing through the worker objects
Write advice that simply executes the join point inside the run() method in the body of the anonymous worker class
Call proceed() from around advice that is inside a run() method of an anonymous class that is implementing Runnable and you get a worker object.
Calling the run() method of such an object - perhaps at a later time or even in another thread - will execute the captured join point.

9. WOC – Example
 demo
Some of the routed calls could be returning a value to the caller. In that case,
proceed() returns the value of the method when the operation has completed.
We can keep this value in the worker object as well as return it from the around
advice. Of course, for the value to make sense, the caller must wait until the execution
of the worker object finishes. In our earlier example, since the caller
thread returns immediately and the operation may execute later, the value
returned to the caller thread will not be the return value of the operation.
To facilitate managing the return value in a generic fashion, let’s write a simple
abstract class, RunnableWithReturn, that implements Runnable. The run() method
in classes implementing RunnableWithReturn must set the _returnValue member
to the return value of the proceed() statement, which is the return value of the
executed join point. Listing 8.6 shows the RunnableWithReturn abstract class.

10. The Wormhole Pattern
The wormhole pattern makes context information from a caller available to a callee – without having to pass the information as a set of parameters to each method in the control flow.
E.g. an authorization system, where many methods need to know who invoked them in order to determine if the caller should be allowed to execute the operation.
By creating a direct route between two levels in the call stack, you create a wormhole and avoid linearly traveling through each layer. This saves you from having to modify the call chain when you want to pass additional context information, and it prevents API pollution.

11. Wormhole - before There are two ways:
Pass additional parameters containing context (API pollution!)
Use thread-specific storage to set and access the context information (requires changes in both caller and callee implementation!)

12. Wormhole – after Specify two pointcuts:
one for the caller
the other for the callee with the former collecting the context to be transferred through the wormhole
Then specify the wormhole at the places of execution of the callee’s join points in the control flow of a caller’s join points

13. Wormhole – after

14. Wormhole – Example
 demo

15. The Exception Introduction Pattern
Your aspects may use commonly available libraries and services to implement the underlying mechanism, such as JDBC for database access or JAAS for authentication; the exceptions they throw are usually checked exceptions
Advice cannot declare that it may be throwing these exceptions, you need another way of dealing with them

16. The Exception Introduction Pattern - Idea
The exception introduction pattern simply suggests that you catch the original checked exception, perform any logic, and throw a new runtime exception that wraps the checked exception.
Propagating the concern-specific exception
Propagating the business-specific exception

17. The Exception Introduction Pattern - Example
 demo

18. The Participant Pattern
Many operations in a system share common characteristics, ranging from simple transactional properties, to expected duration of method calls, to IO-access properties, to remote access properties
Since these operations are spread over many modules, augmenting or altering their behavior is a crosscutting concern.
The participant pattern provides a way to modularize such characteristics-based crosscutting concerns using AspectJ.
surround all slow operations in the system with a wait cursor

19. The Participant Pattern - Idea
Write an abstract aspect that contains abstract pointcut(s) denoting join points with the desired characteristics.
“Aspectual interface”
The aspect also advises each pointcut (or combination of them) with the required behavior. We will think of this as an inviting aspect—it invites others to participate in the advice it offers.
Each class that wants to participate in such a behavior includes a concrete subaspect extending the abstract invitation aspect

20. The Participant Pattern - Example
 demo

21. Idioms - Avoiding infinite recursion
Infinite recursion caused by advice to a join point in the aspect itself is probably the most common problem faced by beginners using AspectJ
 demo

22. Idioms - Nullifying advice
A simple way to nullify advice in the system
 demo
This pointcut will not match any join point, given that it is impossible to evaluate
an if(false) to true. The result, therefore, is the logical removal of the advice
from the system.
A common mistake that is made when trying to achieve the same result with
around advice is to use the if(false) construct to surround the code inside the
advice body, as shown in the following snippet:
void around() : operation() {
if(false) {
...
proceed(); }
While the use of the if(false) construct works well for commenting out a block
of code in Java methods, it doesn’t behave as expected for around advice that
calls proceed() in its body. In this case, if(false) in the advice body results in
bypassing the captured join point.

23. Idioms - Providing empty pointcut definitions
Sometimes you need to supply a pointcut definition that matches no join point in the system
creating concrete subaspects that must define each abstract pointcut in the base aspect but you do not have any matching join points for some of the abstract pointcuts

24. Idioms - Providing a default interface implementation
Use case: class implements a number of interfaces
To prevent extra code one can use this idiom
 demo

25. Idioms – Restricting method calls
Making sure that SQL calls are done only within certain packages
 demo

26. Idioms - matching sub-classes
 demo

27. Links AspectJ in Action, ch. 8
(Eclipse plug-in for analyzing concerns in code)

28. Questions/Comments/Suggestions?
Happy End
Questions/Comments/Suggestions?