Thanks, that does help a bit, though it still quite abstract. Its hard
to picture how a logging mech, employee, etc, would actually get woven
together, usefully.

I have to find some code, that will help.

Sam

Quoteing transami / runbox.com, on Thu, Feb 05, 2004 at 11:16:42AM +0900:
> I think I can give a reasonable overall picture of AOP.
> 
> Think about it from a top-down view-point, as a form of weaving code together, 
> as opposed to the traditional manner of building one block on top of another. 
> So lets say you want to monitor employees. So you create a model of an 
> employee, then you create a logging mechinism, and say a visualizer. AOP 
> allows you to weave these components together describing how they interact, 
> without requiring you to specifically modify any of the code within them. 
> Traditionally you would have built the logging mechinism on top of, or 
> integrated into, the employee model, and likewise with the visualizer. AOP 
> allows you to have much cleaner Seperations Of Concerns --and that's the real 
> point of AOP.
> 
> So an *aspect* then, is one of these concerns, and is said to be orthogonal to 
> the other concerns. The weaving is accompished by describing where code is to 
> be "interwoven" into other code. The code that gets "inserted" is called 
> *advice* (in practice it is defined much like one does a method). This is 
> accomplished by selecting join-points. *Join-points* are specific places in 
> code that can have other advice code inserted into it, and are selectable by 
> some descriptive syntax. This syntax will select a set of joint-points; a set 
> of join-points so selected is reffered to as a *point-cut*.
> 
> HTH,
> T.
> 
>