Catálogo de publicaciones - libros

In this chapter, we presented the aspect-oriented implementation of five well-known design patterns: Singleton, Observer, Command, Chain of Responsibility, and Proxy. For these five cases, the implementation follows this principle: an abstract aspect is defined to hold the code that is generic in the implementation of the pattern. This abstract aspect defines abstract pointcuts that designate the locations in the program where the pattern is to be integrated and the conditions under which the pattern must be triggered. This abstract aspect is then extended to define the code, which is specific to, for example, a command or a proxy. The aspect-oriented implementations of these five design patterns lead to solutions that are more interesting than pure object-oriented, aspect-free implementations. It is, however, not the case for all existing design patterns. Patterns such as the Factory pattern or the Inter- preter pattern do not benefit as much from aspects. Deciding whether a design pattern will benefit from an aspect-oriented implementation is a matter of evaluating whether • The pattern defines a crosscutting structure. • The four criteria of locality, reusability, composition transparency, and (un)pluggability defined by Hannemann and Kiczales are met. • The pattern leaves the structure of the base program unchanged.

In this chapter, you saw how AOP-by verifying that an application’s definition and execution correspond to its identified requirements-can be used to improv e the application’s Quality of Service. First, we showed how AOP can help to implement contracts in a straightforward way. Second, we showed the AOP implementation of two testing techniques: coverage analysis and nonregression tests. Finally, we showed how to use AOP for the seamless integration of JMX with a Java application. Our AOP implementations did not provide more features than the existing tools do. However, our implementations showed how AOP can be used at a developmental level to improve code quality-without n eeding any specific support. Besides, an important advantage of AOP technologies is that it provides the ability to plug and unplug Quality of Service support when needed-even at run time if dynamic AOP tools are used.

This chapter presented a J2EE banking program that was constructed from the Duke’s Bank sample application and showed its organization into projects and packages. This allowed us to explore its architecture and design comprehensively. After reading this chapter, you should now have a basic understanding of the design problems of this application and the ways in which AOP can resolve them. The next two chapters present a detailed account of the use of AOP with this sample application, tier by tier. Although design elements may affect several tiers, it is best to concentrate on one at a time when implementing a design pattern. This allows the projects corresponding to each of the layers to remain independent of each another. For each of the tiers, we will evaluate the improvements offered by AOP according to three criteria: • Improvements in the implementation of th e design patterns used, concentrating on J2EE design patterns • Improvements to a design element that is re cognized as being crosscutting, but that is not an identified design pattern or does not fit within the documented context of a design pattern • Improvements whereby the design depends le ss on the J2EE technologies, especially EJBs As far as the business layer is concerned, we will also evaluate the possibility of replacing automatic integration with a solution using AOP.