Aspect-oriented programming ( P)[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, P 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. |