Geeks With Blogs
Greg Young Greg.ToString()

Tonight was nice, got to actually meet Paul Lockwood for the first time, see Paul Wilson again, talk a length with Doug Tunure (developer evangelist) for the first time, got to meet Wally McClure http://weblogs.asp.net/wallym  and got to meet Keith Nicholson http://www.ksdynamics.com/DesktopDefault.aspx?tabindex=0&tabid=9 who I just realized handed me a card with an Oklahoma address which is kind of neat!

I couldn't have asked for a better introduction tutorial ... Doug spoke about abstraction using base classes and interfaces which really set the tone for AOP (especially mixins).

I am considerring changing the layout a bit to really focus on interception (call injection) and to leave out the mixin structural changes until the end (and to not cover them in an extremely in depth manner). This and more demo time I think would make the subject a bit less abstract. I also always feel like I come accross as that flakey programmer when I discuss AOP, perhaps its the abstractness of the subject (or the fact that I refer to classes in pronouns such as he or she, force of habit) I just always feel like the geologist in “Armageddon“ when I am presenting.

As usual I am unsure of how things went, its a really tough topic to get a feeling for how the room is grasping the material (so long as I don't see a bunch of forum posts in the next few days about why they can't apply an interceptor to a non-virtual method I will be happy :))

I was quite happy when someone asked if the Repository pattern would help with the Save/Delete methods (they are a contrived example not something out of my code :D), glad to see DDD slowly spreading through the C# community. I forgot to mention to the gentleman who has asked but Jimmy Nilsson actually has a chapter in his upcoming book which discusses AOP in the domain layer! it has alot of uses there (as examples http://geekswithblogs.net/gyoung/archive/2006/03/15/72374.aspx or think about all of the interfaces you tend to have that end up with library methods being called passing “this“)

A few questions came up at the end that were fairly interesting, I didn't have a whole lot of time to address...

Overhead of interception
This really depends on the framework that you are using and the methodologies it employs to make the physical call to the subject object; some use reflections, some use delegates, and some actually insert calls directly into the generated proxy. At first glance it would seem that the direct insertion of calls would be the most performant with the delegates coming in a close second in 2.0, there is an issue with the direct calls though. When I use direct calls from the proxy, I have to regenerate a new proxy if any of that information changes, with the reflection and the delegate method the chaining process is moved out of the proxy so a more generic proxy can be built.
 
I had said that in my experience it tended to be a 1-4% increase on average. When I say a 1-4% increase I am taking into account the entirety of the operation (and looking at a large sampling of operations). For example I have a method that writes to a bufferred log, by moving this code to an aspect I incur on average a 1-4% hit on the overall operation in the indirection. This is obviously a subjective number as it depends wholely upon what you are doing in your aspects. If I were for instance to make an aspect that was run on every pixel in an image and it was doing a simple operation such as R = R * 2 % 256 the indirection would in fact be more expensive that the original code. That said I highly recommend you not use aspects to provide such behaviors.
 
Over use of aspects and design decision making
The best analogy I can come up with for you is a comparison to analysis of pattern use. When we design OO based systems we could go quite pattern happy, while our system would become more flexible it would also become slower and alot more complex (think about creating every object through a factory or having a bridge for every object (both add a level of indirection)). Obviously some level of when to provide such items comes with experience and domain knowledge (what is the likelyhood of my foo object later needing polymorphism) the same is true with aspects. Another common way of solving this problem is a risk analysis.
 
In deciding whether or not to introduce the concept of an aspect to my domain I have to first analyze my current risk and compare that to the complexity it will add. I would most likely need to have a significantly sized domain with a good number of cross cutting concerns in order to introduce the complexity to start with. If for instance I had a domain of 9 classes with 2 cross cutting concerns in each, the risk probably does not require me to even consider aspects as an option (a sweeping change would force 18 changes which can probably be implemented very quickly). The argument is similar once the complexity of an aspect has been introduced into the domain.
 
If I have a cross cutting concern that exists within two places and is not likely to re-appear in my domain I can again quickly analyze the risk associated with the concern, a sweeping change will require two code changes. If however I have a concern that is in 4000 places (unit of work dirty object registration is a wonderful example) and the risk of its implementation changing is real, then moving the concern to an aspect makes alot of sense.
 
One thing I feel is important in this is that domains in the context that I am using are not domains as described within say Eric Evans' work. A domain in this case is actually your entire code base. A main goal of AOP is to allow me to modularize cross cutting concerns that span applications, an example of this could be seen in a simple logging aspect. Once my logging aspect is created I can re-use that aspect in any new application that I create that uses aspects.
 
If you are familiar with the often used layerring models (i.e. presentation, domain, dal with a system layer on the side that all share as a simple one), moving my concerns to aspects allows me to remove them from a given layer and move them out to the system layer promoting their re-usability.
Posted on Monday, March 27, 2006 8:27 PM | Back to top


Comments on this post: Finished AOP Presentation

# re: Finished AOP Presentation
Requesting Gravatar...
Geez, you act like I am somebody special.......
Left by wallym on Apr 07, 2006 9:48 AM

Your comment:
 (will show your gravatar)


Copyright © Greg Young | Powered by: GeeksWithBlogs.net