Explicación sencilla de Aspect Oriented Programming (AOP)
Esta explicación aparece en http://www.ibm.com/developerworks/rational/library/dec07/temnenco/index.html. Me pareció buena pues es breve, orientada a código y sencilla.
The AOP paradigm
Unlike the AOA, the modular design approach currently widely employed in programming entails breaking down an application into physical parts — such as components, modules, classes, methods, etc. — that have minimal functional overlap and encapsulate implementation of the specific concern or a number of concerns. In this regard, a concern can be anything from a narrowly defined business or system problem (e.g.,”withdraw money” or “display user message”) to an area of interest or focus (e.g., “security” or “auditing”). Unfortunately, cleanly separating the concern into a module is not always possible, because other concerns tend to cut in. For instance, “withdraw money” is typically intertwined in the program code with “security” and “logging,” as shown in Table 1 below:
Table 1: The concern “withdraw money” intertwines in the program code with the separate concerns “security” and “logging” in this example of the modular-design business method.
|
The three separate concerns shown — “withdraw money,” “security,” and “logging” — are tangled in this relatively simple method. This lack of separation would be a minor issue if the concerns were not used in other places in the application; however, “security” and “logging” are used in many other business methods, which qualifies them as “cross-cutting concerns” as opposed to simple business logic concerns.
AOP separates the code for concerns into modules called “aspects.” The aspect code is also referred to as “advice.” The advice executes when a rule, known as a “join point,” evaluates to true. Join points are encapsulated in quantifiable expressions (queries) called “pointcuts.”
Leave a comment