Filippo just posted a couple of thoughts about AOP and what he called "Dependency-Oriented Programming". There was a lot of discussion about this almost a year ago on this very blog, but we called it 'Quantum AOP'
back then, and now I feel like going back and updating those posts to
use this new name. Dependency Oriented Programming is just the buzzword
this thing was waiting for! :)
So, almost a year later, AOP - and AspectWerkz
in particular - went through some pretty major steps. It's just not
that weird and strange academic fancypants stuff anymore, lots of
people have used it in their day jobs to solve some real world
problems, and I feel like there's some feedback from my
experimentations in this field lacking on this blog. So here we go.
In late March last year I started developing a content management
system using mostly introductions, or mixins, which I prefer calling
them, to define associations between objects. And not just that: I used
mixins for pretty much everything; my business objects were kept empty
except for one or two static helper methods, or some piece of data that
really wouldn't be useful anywhere else. To recap, this is what my
Content class looked like:
public class Content {}
Later, using AspectWerkz (version 0.3 at the time), I'd add behaviour
and data to this class using some mixins. For example, HasName:
public class HasNameImpl implements HasName {
private String name;
public void setName(String name) { this.name = name; }
public String getName() { return name; }
}
Not taking into consideration the actual implementation details, like
the XML configuration for AspectWerkz (which changed quite a lot in the
recent releases), this is pretty much what Filippo ended up with, too.
One of my major concerns at the time was the awful lot of casting
required to make any mixed in method call to the target class work, and
I ended up using WebWork's JavaScript actions to solve that (as
JavaScript is a dynamic language, there's no need for explicit casts).
With that problem basically solved, the other big one was keeping the
codebase manageable, because if i'd have an interface, a class and a
chunk of XML for every "atom", I'd end up with tons of files on my
source tree and a huge XML definition pretty easily as I added new features to the system.
And that unfortunately happened, leaving the codebase pretty messy
before I had the time to think of a fix. I moved on to some other
things in the meantime, so that fix is still pending, and sometimes I
still catch myself trying to figure out a way, but, so far, nothing
really interesting came up. Rickard's abstract aspects
were a step in the right direction, I think, but there's still
something missing on the manageability side of AOP (there I go using
the 'm' word again!). Am I missing something?
Previous Topic
