October 29, 2008
Aspect-Oriented Programming On The CheapIf you're sat at home alone twiddling your thumbs - or whatever it is that you twiddle when you're sat at home alone - why not take on a little project to keep your mind and your thumbs (or whatever) busy?
In spare moments - which these days come mainly while I'm on the crapper (if you only count the spare moments when I'm awake and sober) - I'm pondering the whole problem of cross-cutting concerns and what to do about them.
If you're not sure what I'm flabbering on about, a cross-cutting concern is a piece of logic that, because of the limitations of procedural and OO programming langauges, gets spread throughout the software causing much heartache and howsyourfather when the inevitable time comes when we have to make a small change to that piece of logic.
For example, say we wanted to log every public method call. This is not easy to do in a language like C# or Java or Ruby. Or Commodore BASIC, come to that. We end up with a block of code inside each public method that has to be invoked before the body of that method. If we decide to change the way the logging interface works, then there'll be tears before bedtime. We'll be forced to make that change in every public method. Boo hoo!
Yes, I know we have a way around that now. It's called aspect-oriented programming. And it's mighty fine for dealing with cross-cutting concerns. In an AO language, we can put all our logging code into a single aspect and then specify that it must be invoked before the body of every public method. Simple as. Bish bosh.
Then if we want to change the logging interface, we only need to do it inside that aspect. or if we decide that we only want to keep a log of methods called that begin with the letter "P" (it could happen) then we just change the rules about where our aspect is to be invoked, and it's done.
There's just one fly in the ointment. Who gets to use aspect-oriented programming languages? Most development organisations I know are still living in the 70's, where objects and windows and instant soup with croutons are considered space age technology, and they are unsurprisingly very reluctant to dip their toes into super-modern AOP water. To your average CTO, AOP comes from the future - probably sent back to kill John Connor and wipe out the resistence.
It's new. It sounds complicated. It sounds risky. Will it actually work? Who will support it? Where do we hire AO programmers? Are they expensive?
So most of us don't get to keep AOP in our toolbox of potential solutions. We make do with scattering cross-cutting concerns through our code and suffer the inevitable consequences.
But it needn't be like that. I reckon some bright spark out there (he may be called "Antony" and live in Penge - who can tell?) might be able to cobble together a sort of "AOP-lite" in a language like C# using things like attributes, reflection and dynamic code generation.
Let's imagine, for example, an attribute called Aspect that you can apply to a class. And in this class you specify some behaviour, and even find a way to pass in instance variables (perhaps in an array) and info about the calling method. And let's say you had another custom attribute called Pointcut that took, as an argument, a regular expression that described a set of method signatures that the behaviour should be applied to.
Finally, a custom attribute called Advice could be used to attach a body of code to be executed at the join point in the code picked out by a pointcut.
It's not the whole AOP shooting match, but I reckon someone with their thinking cap on could put together a passable .NET library that would allow developers to specify basic aspects, pointcuts and advice to enable maybe 80% of what a language like AspectSharp could do. And it would do it using vanilla .NET and C#, so no need to go cap-in-hand to the boss for permission.
That would be a nice little open source project for someone (perhaps called Josh, for example. I couldn't possibly say.)
Posted 10 years, 10 months ago on October 29, 2008