This chapter is from the book
This chapter is from the book
This chapter is from the book
2.8 Evaluating the Implementation
We can see then from the tools that the advice we wrote seems to be calling notifyListeners() at all the right times. We're not finished yet though because we still have all the old calls to notifyListeners() scattered throughout the policy classes, and we haven't run the test suite.
We want to know that all the tests would still pass with the PolicyChangeNotification aspect in place, and all the old calls to notifyListeners() removed. Ideally we would like to know that now, before we actually go ahead and remove all those calls, because that will be a smaller step if we find we have to backtrack. We are going to show you an AspectJ technique you can use to do this. Remember we said that AspectJ supports several kinds of advice, including around advice. Around advice gives you complete control over the execution of a matched join point. One of the things you can do with around advice is decide whether and when the computation at the matched join point should proceed. A "no-op" around advice implementation looks like this:
Object around() : somePointcut() {
return proceed();
}
It does nothing before proceeding with the computation at the join point, and returns immediately that computation has completed. As a transition stage in the development of the PolicyChangeNotification aspect, we can add the following around advice to the aspect:
void around() : notifyingListeners() &&
!within(PolicyChangeNotification)
{
}
Because it contains no call to proceed, this advice has the effect of bypassing the computation at join points it matches. We previously defined the notifyingListeners pointcut to match all calls to notifyListeners, so this advice effectively removes all those calls that aren't made by our aspect from the runtime execution of the program—it lets us run the test cases and see what would happen if the calls weren't there. We should stress at this point that we are only using empty around advice as a transition stage in our refactoring. We do not advise you to create programs that use around advice to "stub out" unwanted calls as a permanent part of the design. See the next chapter for an example of the use of around advice as part of the program design.
With this temporary around advice in place, we can run the test suite. The results are shown in Figure 2.38. A test case has failed!
)
Figure
2.38 A failing test case.
What's going on? We can double-click in the JUnit view to go to the test case definition. The editor opens on the test case, with the failing assert highlighted (see Figure 2.39).
)
Figure
2.39 The failing test case definition.
You can see that the test case adds a new claim against a policy, and then checks to see that a notification of update was received. The method called to add the new claim against the policy is addClaim. We defined the policyStateUpdate pointcut to match the execution of methods beginning with "set" on policy objects. "addClaim" does not fit this pattern—our pointcut definition is not quite correct. If we open the editor on the PolicyImpl class, we can see what's going on (see Figure 2.40).
)
Figure
2.40 Clues in the editor.
Notice that the setClaims method has an after advice marker next to it in the left margin. The addClaim method has no such advice marker—although it does have a warning marker because the old implementation contains a call to notifyListeners. Another clue is in the ruler in the right margin. You can see that the advice markers and warning markers are nicely paired throughout the file, apart from the last two (highlighted), which have warnings but no advice markers. These warnings are against the addClaim and removeClaim methods.
Aspects aren't a silver bullet—you can use them to improve the modularity of your programs, but they don't alleviate the need for test-driven development or any of the other best practices you have learned from working with Java.
2.8.1 Updating the Pointcut Declaration
Let's go back to the PolicyChangeNotification aspect and update the definition of the policyStateChange pointcut. We want to match join points that represent either the execution of a "set" method, or the "addClaim" method, or the "removeClaim" method. Figure 2.41shows the updated pointcut definition.
)
Figure
2.41 The updated pointcut definition.
We can use either the Outline view or the editor to check that we are now indeed matching the execution of the add and remove claim methods. Figure 2.42shows how the PolicyImpl.java source file looks in the editor now.
)
Figure
2.42 New matches as a result of the updated pointcut.
Notice that the advice markers are now appearing next to the addClaim and removeClaim methods. In the right margin you can also see that the advice markers and the warnings are now balanced: every time there is a call to notifyListeners coded in the PolicyImpl class, there is also advice in effect to achieve the same result. Now when we re-run the test cases, they all pass.
2.8.2 Removing the Old Calls to Notify
Now the time has come to remove all the calls to notifyListeners that are scattered throughout the classes in the policy hierarchy. We can use the warning tasks in the Problems view (see Figure 2.27) to navigate to all the offending places and remove the call. Now we can take out the around advice as well, and the job is done. Save all the files and re-run the test cases—they all pass.
){kind=link}
Figure 2.43 shows the completed PolicyChangeNotification aspect.
)
Figure
2.43 The finished aspect.
2.8.3 Comparing the Modular and Non-modular Implementations
While working through the tasks in the Problems view removing all the unwanted calls to notifyListeners, we noticed an interesting case in the LifePolicyImpl class. This is shown in Figure 2.44.
)
Figure
2.44 Ironman.
Notice that the setDrinker method contained a call to notifyListeners, but the call to setIronman a little farther down in the source file did not. This was a bug in the original implementation. How did this happen? Originally Simple Insurers Inc. just sold ordinary life policies pretty much like every other insurance company. Sometime after the original LifePolicyImpl class was written, the marketing department decided that anyone fit enough to compete in an Ironman competition ought to be a pretty good prospect for life insurance, and decided to go after the market niche with special discounts. The programmer that added the ironman field into the LifePolicyImpl class forgot to add in the call to notifyListeners.
The PolicyChangeNotification aspect does notify listeners after the ironman field has been updated. Because the pointcut specifies by property (all the set methods) rather than by exhaustive enumeration when a notification should be issued, it gets it right. In our experience, it is fairly common for an aspect-based implementation such as this to be more accurate than the scattered, hand-coded alternative.