and return the value to the caller. These small things can allow spurious errors to creep into your
application. By keeping the advice type as focused as possible, you reduce the scope for errors.
Advisors and Pointcuts in Spring
Thus far, all the examples you have seen have used the ProxyFactory.addAdvice() method to configure
advice for a proxy. As we mentioned earlier, this method delegates to addAdvisor() behind the scenes,
creating an instance of DefaultPointcutAdvisor and configuring it with a pointcut that points to all
methods. In this way, the advice is deemed to apply to all methods on the target. In some cases, such as
when you are using AOP for logging purposes, this may be desirable, but in other cases you may want to
limit the methods to which an advice applies.
Of course, you could simply perform the checking in the advice itself that the method being advised
is the correct one, but this approach has several drawbacks. First, hard-coding the list of acceptable
methods into the advice reduces the advice's reusability. By using pointcuts, you can configure the
methods to which an advice applies, without needing to put this code inside the advice; this clearly
increases the reuse value of the advice. The second and third drawbacks with hard-coding the list of
methods into the advice are performance related. To check the method being advised in the advice, you
need to perform the check each time any method on the target is invoked. This clearly reduces the
performance of your application. When you use pointcuts, the check is performed once for each
method, and the results are cached for later use. The other performance-related drawback of not using
pointcuts to restrict the list-advised methods is that Spring can make optimizations for nonadvised
methods when creating a proxy, which results in faster invocations on nonadvised methods. These
optimizations are covered in greater detail when we discuss proxies later in the chapter.
We strongly recommend that you avoid the temptation to hard-code method checks into your
advice and instead use pointcuts wherever possible to govern the applicability of advice to methods on
the target. That said, in some cases it is necessary to hard-code the checks into your advice. Consider the
earlier example of the after-returning advice designed to catch weak keys generated by the KeyGenerator
class. This kind of advice is closely coupled to the class it is advising, and it is wise to check inside the
advice to ensure that it is applied to the correct type. We refer to this coupling between advice and target
as target affinity. In general, you should use pointcuts when your advice has little or no target affinity--
that is, it can apply to any type or a wide range of types. When your advice has strong target affinity, try
to check that the advice is being used correctly in the advice itself; this helps reduce head-scratching
errors when an advice is misused. We also recommend you avoid advising methods needlessly. As you
will see, this results in a noticeable drop in invocation speed that can have a large impact on the overall
performance of your application.
The Pointcut Interface
Pointcuts in Spring are created by implementing the Pointcut interface, as shown in Listing 6-19.
Listing 6-19. The Pointcut Interface
package org.springframework.aop;
public interface Pointcut {
ClassFilter getClassFilter ();
MethodMatcher getMethodMatcher();
}
Search WWH :
