AOP use cases

[Jacek Generowicz]

Peter Hansen <peter at engcorp.com> writes:

> Jacek Generowicz wrote:
> (a lengthy reply, and thank you for taking the time!)
> > Peter Hansen <peter at engcorp.com> writes:
> >>I would be very interested to hear some real-world and real useful
> >>use cases for AOP as well.
> > AOP is about separation of concerns. Let me repeat that: AOP is about
> 
> >           SEPARATION OF CONCERNS.
> [snip]
> > As for real world examples ... if you think of AOP as separation of
> > concerns which you want to be weaved together, then I am sure that you
> > will be able to come up with plenty of excellent real world examples
> > yourself.
> 
> Unfortunately, that's just my point.  So far I haven't been able
> to do that, it seems.

> The example posted previously with the "synchronization wrapper"
> approach is, however, quite understandable and comes from real-world
> experience that many of us share.  Is that AOP?  Is it not AOP?

Well, that depends on what you think AOP is. If you think that AOP is
Kiczales' work in Java, then clearly the synchronization wrapper isn't
AOP. If you think of AOP as separation of concerns, then the
synchornization wrapper is AOP ... but then so are optimizing
compilers. I am partial to a view somewhere in between those two
extremes ... maybe viewing AOP as a pattern.

But "AOP" is a buzzphrase and it's probably best not to get too hung
up on buzzphrases. I would prefer to see the ideas behind it and to
try to apply any that have merit where they may help me. "Separation
of concerns" summarizes something towards which I've been striving,
even unconciously, before I ever heard of AOP, but seeing it as an
active field of study encourages me to believe that it might become
easier to separate concerns in my programs, either through language
support, or people discovering neat ways of achieving it in various
languages.

> If it's an application of AOP principles, then is AOP anything other
> than a good practice which some of us have been doing for years,
> prettied up with a nice name.  In other words, Just Another Pattern?

Yes, I think that you are justified, to some extent, to view it as
just another pattern. Of course, some languages make it easier to do
AOP as a pattern, while others require external help, while in others
still it's so trivial that it doesn't even merit being called a
pattern:

   Consider multiple dispatch in Common Lisp, C++ and C; in C++ it's a
   pattern (Visitor), in CL it just is, and in C ... ?
   
   How about the State Pattern? "foo.__class__ = bar" is how you do it
   in Python, is that a pattern?
   
   How about OOP in C++ and C? in C++ it just is, and in C it's a
   pattern (or requires external help: ie somebody coming along and
   implementing C++ or Objective C).

So, maybe AOP is a technology in Java, a pattern in Python, and just
is in the CLOS MOP ?

(Hmm, I recall a pertinent anecdote about this ... let's see if I can
find it ... here it is

Message id: <quCac.12983$1C1.5962031 at twister.nyc.rr.com> :

   I am reminded of Gregor Kiczales (sp?) at ILC 2003 displaying some
   AspectJ to a silent crowd, pausing, then plaintively adding, "When
   I show that to Java programmers they stand up and cheer."
)

> You seem to be someone who understands AOP well:

Oh lawd, I never intended to create such an illision !

I like to think that one of my merits is trying (and sometimes even
succeeding) to see past all the noise and hype surrounding something
and understaing, in as simple terms as possible, what the essence of
it is. It is from this perspective that I offered my article: I know
essentially bugger all about AOP in Java, but I believe that AOP is
about separation of concerns. If you look at it that way, next time
you are come across the need to separate concerns, a little bell might
ring and you might think of AOP. How you go about separating those
concerns is strongly dependent on the language you happen to be using.

> do you use it?

Certainly not in the Java sense.

Unfortunately I'm stuck mostly in C++ hell, but I suspect that
separation of concerns creeps into my Python code (when I get to write
some), probably even without me explicitly identifying it a such.

> Could you please provide an example from your own uses which
> demonstrates the effectiveness of AOP versus "not AOP" in the same
> way that the synchronization example posted earlier is clearly
> better when done as a wrapper than with the code duplicated
> everywhere (i.e. with the "concerns" not separated)?

Not offhand. If I notice some neat separation of concerns in my work
I'll try to remember to post it.


Sorry, this ended up much longer than it should have been.