AOP use cases

[Joe Mason]

In article <AZ-dnUNqC9-oUh3dRVn-jw at powergate.ca>, Peter Hansen wrote:
> Joe Mason wrote:
>> In article <35qdnT4kNsX1kB3dRVn-gg at powergate.ca>, Peter Hansen wrote:
>> 
>>>The logging example is okay, yes, but another problem I have
>>>with it is that it's very development-oriented.  It doesn't
>>>do anything directly for the user in terms of helping implement
>>>user functionality.  Same goes for the contract aspect, which
>> 
>> 
>> It does if generating usage reports is a user requirement.  Call logging
>> in a telephony app, for instance.
> 
> Sorry, but that doesn't fly.  That's a clearly separate function
> that should have a simple, single call somewhere in the application.

Not at all.  You'll want to log when calls start and end, when features
are turned on and off, when specific services (voice mail, call
forwarding) are accessed.  If your app is for a call center, you want to
log when people go on and off hold and when they enter specific service
queues.  Two years down the road a major customer will want to buy your
system, except they have incredibly specific requirements for report
generation which requires you to add even more entry points...

> The AOP logging example is talking about a "cross-cutting concern"
> (did I get that right?) where one wants to log *all method calls*
> in an object.  It's a developer tool, not something that you would
> use for call logging.

No, where one can dynamically decide which method calls to log.  The
point of "cross-cutting" is that you have the voice mail modules, and
the call forwarding module, and the service queue module, and they *all*
have to do logging.  The examples just add to all methods of an object
because it's an easy demonstration.

Joe