 |
Articles - Frank |
|
JDBC Patterns
XMLTalk Frames Part 1 Frames Part 2 AOP 101 |
|
|
Articles - Eileen |
|
I. Why use OO?
II. Casting Objects I. Why use AOP? II. Misc AOP |
|
|
Quick Refs |
|
EJB 2.0 Matrix
EJB Exceptions |
|
Part II: Miscellaneous Notes - AOP
More on Persistence
The first article was meant to give a glimpse of what AOP does for cross-cutting concerns. However, the example is way too simplified. Some food for thought for changes necessary to enhance that framework (Frank has done this in a week's worth of time):- Pointcutting the setter methods is not enough. What about the Collection classes? Every time you add/remove an element from a Collection, you're also changing data...
- How do you add transactional behavior? And nested transactional behavior (which, it turns out, has to be done in a tree, not in a stack)
- How do you handle multi-threading?
- Some developments in later stages: the framework got incredibly messy and had to be refactored, but when it was refactored, several seemingly critical pointcuts magically disappeared.
- Some limitations in the language: certain constructs don't work correctly in inheritance hierarchies with abstract superclasses.
- This exercise has been good in flushing out bugs and limitations, in fact, check the AspectJ support mailing lists, Frank has already put in requests for future features.
Different Approaches
It turns out there are a number of different schools working on different areas of aspect programming. Here are the major camps:- AspectJ - specifically for handling cross-cutting concerns, this is what the first article focused on
- HyperJ - by IBM. This is totally different. The basic premise is this: say you build a domain model for an HR system, and later are asked to build a system for sales. Well, it turns out, the domain model for sales is different from the one built for HR, but there are some similarities. HyperJ deals with "multi-dimensional composition", or taking these multiple "hyper-slices" and figuring out how to merge them. To me, it seems AspectJ is the "plumbing" that might be used to build something like what HyperJ does.
- Composition filtering - pioneered by the guys at University of Twente in Holland, some were Frank's classmates. You'd have to ask him more about this; whether or not it differs from aspect programming or is simply a precursory term to aspect programming. They might be different.
- Miscellaneous other angles:
- DemeterJ
- DJ
- COOL/RIDL
- SALLY
- AspectC - yes, don't be fooled. "Aspect-oriented" seems to imply that this is the next step in the evolutionary process to object-oriented programming, when in reality, aspects and OO are orthogonal technologies. Nonetheless, people who "take to this" tend to be people with solid experience with design patterns and object-oriented programming.
Random Thoughts
This is similar to the game "Go". 5 minutes to learn (e.g. the syntax of AspectJ), a lifetime to master. - FS Object models are two-dimensional, when in reality, we live in a multi-dimensional world. A cross-cutting concern is an indication that we're trying to model something in the wrong dimension. Join points are like wormholes into these dimensions that were, until now, inaccessible. How did we ever operate without AOP? - CC and FS Because of aspects, you can now build interfaces that have methods with bodies and normal variables. Although when you decompile the code, it looks like it shouldn't even compile... Tip: Using jad.exe to decompile the final bytecode really helps in terms of learning how to code aspects correctly, as well as optimize them. Another good example: adding memoization to the doubly recursive Fibonacci algorithm. Problem: you want to optimize, but you don't want the optimization code cluttering up your algorithm. Many of the GoF design patterns can be implemented much more elegantly using aspects, e.g. Observer.
|
||||||||