- Software Development and the Object-Oriented Paradigm
- The Case for Aspects
- What Is an Aspect?
- Why Consider Aspects in Analysis and Design?
- Aspects and Other Concerns
- The Theme Approach
- Applying the Theme Approach
- Theme: Symmetric or Asymmetric?
- Fitting Theme into Your Existing Development Process
- What About Implementation?
The Case for Aspects
We know that a program must be correct and we can study it from that viewpoint only; we also know that it should be efficient and we can study its efficiency on another day. . . . But nothing is gained—on the contrary—by tackling these various aspects simultaneously. It is what I sometimes have called "the separation of concerns."
Aspect-oriented programming (AOP)2 was introduced to provide a solution to the scattering and tangling described above. It is often described as liberating developers from the hegemony of the dominant decomposition.3 Simply put, this means that whichever modularity you choose (objects, functions, etc.) will at some point impose unwanted constraints on your design. In the object-oriented case, the dominant decomposition is the modularity of classes, and methods. The hegemony refers to the fact that when pinned to object-orientation, developers are forced to make design decisions that lead to scattering and tangling. In some cases, developers must be able to break out of that modularity and design code that crosscuts an object model.
AOP allows a developer to program those crosscutting portions of a system separately from any of these structural entities. Even though in its infancy, AOP has proven to be of great use in modularizing source code and has provided a wide spectrum of benefits, from performance enhancement to more evolvable code. Aspect-oriented languages provide support for programming such crosscutting concerns, or aspects, in one place and then automatically propagating the behavior to the many appropriate points of execution in the code. In this way, aspects allow a developer to specify behavior that overlays an existing class model.
However, aspects certainly should not be used as the hammer for every nail. Just as considering when to use inheritance, it is important to consider when an aspect is an appropriate choice for some functionality. Nonetheless, aspect-orientation has been shown, when used properly and appropriately, to transform necessarily hairy code into something manageable and reasonable.