Response: Rickard's AOP thoughts
  Posted October 16, 2002    PermaLink    Comments (0)  

Rickard posted some thoughts on AOP and I must say it is amazing how some of those items could be done in non-java without the pre-processors (thought not in the same language). To me AOP is just like OOP and structured programming before it: principally a practice. It is also a practice that is re-enforced and simplified by language constructs.

(However I would like to say that EJB is an example of seperation of concers; as long as what you are concerned about what EJBs are concerned about.)

Here goes. AOP, to me, is two things: first, you get to pick objects apart into smaller parts each of which has a nice clearly defined purpose. These parts can then be assembled to form big objects. [ Random Thoughts ]

As you go on to read further what started registering in my head was *hushed*tone* Multiple Inheritance *gasp*. What it is closer to however, is the OOP pattern composition. I haven't seen this achieved that often except in rather brittle examples. When you think about it though composition is a OOP way to achieve separation of concerns. It was the casting example that made me jump out and say that it can also be accomplished via multiple inheritance. But in that case you lose the possibility of composing the object of sub-classes of the pieces, like a V-8 engine for a Denali v.s. a 3-cylinder for a Geo Metro. At a cursory glacne it appears that using AOP to gain this type of composition also suffers from this flaw. What if I want Unix type User-Group-Other ACLs on some and NTFS every-possible-permutation style ACLs on other objects? You could flatten out the classes and make two ACL type. But this false when that choice varies not based on type of object but arbitrarily per object. For example: some pages kept on client A's extfx system and some on client B's NTFS but both aggregated in the same place. That's why I don't see how (ACL)page has any intrinsic value (other than aesthetics) over page.getACL(), in fact it seems that the latter is better in that sense.

However, this is a red herring over what AOP is providing, in that when following the principals of AOP you can do either to achieve composition. What is important is that you don't litter the ACL code special cases in with the other items and keep ACL code i the ACL. It seems to me that if you cannot keep ACL code in one place perhaps the concerns are not separated properly or they are not separable. Keeping the concerns separated is alot easier when the language and framework are designed with separation of concerns in mind.

Second, AOP is also about what most people would call "interceptors". That is, doing stuff before and after a method call on an object. [ Random Thoughts ]

What came to my mind from this paragraph is function pointers, or as Microsoft calls them toady delegates. Also C macros are quite crafty in that regard. For function pointers you could write a method to do the work around the method and then call the other method, and store it with the other method. But to do it arbitrarily to arbitrary code you would need (1) to make all function call through pointers and (2) some place to store what the previous function was. To accomplish 2 you would need to pass some overhead like a pointer to a stack of methods to know what the next one is, which is exactly what AspectJ and what Rickard's code example do.

It is crucial to remember here that while the object being referenced in client code may implement 10 interfaces, there is no class (beyond the dynamic proxy class) that actually implements all of those. They only implement one interface, and the AOP framework takes care of the routing from this big happy I-got-it-all "object" to these smaller objects. All of that is transparent to the developer though. [ Random Thoughts ]

One object that can accept any message... hmm... doesn't SmallTalk allow any message to be sent to any other object? Seems to me more and more AOP languages are talking the shiniest pieces of other languages and making them their own. Sure you could do it in C, but you wouldn't want to since void * is a great way to fumble the memory heap.

This feels like going through the candy store and throwing out the blue SweetTarts, M&Ms with peanuts, and anything made with dark chocolate. How can anyone like dark chocolate?

Trackback URL
  TrackBack URL for this entry:
Post Comment

Thanks for signing in, . Now you can comment. (sign out)

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)

Remember me?

Email Address: