AOP use cases

John Roth newsgroups at jhrothjr.com
Thu Apr 22 06:58:17 EDT 2004


"Peter Hansen" <peter at engcorp.com> wrote in message
news:XYmdnVLB9rjbARrdRVn-vg at powergate.ca...
> 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?  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?
>
> Jacek, I appreciate the attempt to clarify, but so far it seems to
> me that *everyone* who talks about AOP just talks in abstract terms
> and isn't willing (or able?) to pin it down with *real* real-world
> examples, just "imagine this" or "wouldn't it be nice if".  You
> seem to be someone who understands AOP well: do you use it?  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)?

Oh, absolutely. "Separation of concerns" is all very nice, but it's
simply another way of looking at program composability. And
composability has turned out to be a very hard problem: there are
no, and I mean no, examples of composable programs where there
was no planning on making it happen.

The other thing to note is that "separation of concerns" imposes
significant overhead, and I'm not just talking about performance.
It cuts down on communication, code sharing and any possibility
of finding structural congruence that might lead to deeper understanding.

John Roth
>
> -Peter





More information about the Python-list mailing list