AOP use cases

Daniel Dittmar daniel.dittmar at sap.com
Thu Apr 22 08:59:17 EDT 2004


Jacek Generowicz wrote:
>>>           SEPARATION OF CONCERNS. [snip]

C moved the I/O from the language to a library. This is separation of
concerns, but I wouldn't call it AOP.

My idea of AOP vs. OOP is about hooks or variation points: ways to customize
existing code.

OOP added two kinds of variation points: interfaces and calls of virtual
methods (yes, the two are closely related). When I have a method a, I can
- self.b (): add a call to a virtual method b of self: the behaviour of
method a can be changed by implementing a subclass and overriding b
- x.c (): add a call to a virtual method c of variable x: the behaviour of
method a can be changed by passing a different kind of x into the method

Both of these hooks must be provided be the implementor of a, he/she must
add calls self.b () and x.c ().

AOP tries to add hooks that are provided by the structure of the program so
that the programmer doesn't have to add them by hand:
- method entry and exit
- creation of objects
- calls to methods
- module import
- ...

Those of you using XML might want to visualize the program as a DOM tree and
AOP as applying a XSLT stylesheet. (Now visualize applying several different
stylesheets in arbitrary order)

This works probably best if each short rule matches many individual hooks.
This is why the logging example is so compelling. If many rules match only
one individual hook, then you have 'mincemeat of concerns'.

Daniel






More information about the Python-list mailing list