Let's call the original functionality F, the guard functionality G and the sum functionality H.
The most common approach has always been to take F and bury it under an API. You can then mix G throughout, without any other code being aware. Any changes to the guarded code are thus localized and easier to modify, but the up-front effort can be annoying.
The standard idiom for functional languages is to make G a function that takes a function as an argument. Calling H passes F to G. G does the setup work, calls F, does teardown work and returns F's value. Scheme's call-with-input-file is a good example of this. The changes necessary to turn F into H are smaller, and F and G are much more cleanly separated. And it's clear what's going on in the code.
I think the best way of approaching Aspects is to compare them to operator overloading: if you're programming in a domain where it's a natural technique, it's wonderful (that was my experience doing 3-D graphics in C++); if you're using it for averything else, you're probably going to confuse the next person looking at your code. I think Aspects are a natural technique for any sort of instrumenting.
It would be amusing to survey the AOP/AspectJ boosters on what they think of operator overloading.
With stock Java, you can inspect a particular method and know almost exactly what it does. It's a lot of work; you have to examine:
the instructions inside the method
the arguments to the method
the instance variables and the methods of the containing class
the instance variables and methods of the parent classes
the contracts of any classes you have to be using
It's annoying to do but the lexical structure of the language makes it clear where you have to look. The only exception is when derived classes override methods in the class you're examining. (And this is a problem with every class-based OO language out there.) If the method is "abstract", though, at least you have some indication to look elsewhere.
AspectJ messes this up badly, because you can no longer tell what's going on by tracing code. To understand the behavior of a method, you have to do everything you did before, plus know and understand every single Aspect defined for your program, since any of them may change any of:
The behavior at the beginning or end of your method
The behavior at any function call in your method
The parent of the class
Aspect weaving is useful---it makes up for some of the lack of power of Java---but if Grady Booch's hype machine is successful, he'll sell a lot of books, people will use a lot of Aspects, and no one will be able to tell what is going on in their programs.
Slashdot Mirror
Let's call the original functionality F, the guard functionality G and the sum functionality H.
The most common approach has always been to take F and bury it under an API. You can then mix G throughout, without any other code being aware. Any changes to the guarded code are thus localized and easier to modify, but the up-front effort can be annoying.
The standard idiom for functional languages is to make G a function that takes a function as an argument. Calling H passes F to G. G does the setup work, calls F, does teardown work and returns F's value. Scheme's call-with-input-file is a good example of this. The changes necessary to turn F into H are smaller, and F and G are much more cleanly separated. And it's clear what's going on in the code.
I think the best way of approaching Aspects is to compare them to operator overloading: if you're programming in a domain where it's a natural technique, it's wonderful (that was my experience doing 3-D graphics in C++); if you're using it for averything else, you're probably going to confuse the next person looking at your code. I think Aspects are a natural technique for any sort of instrumenting.
It would be amusing to survey the AOP/AspectJ boosters on what they think of operator overloading.
With stock Java, you can inspect a particular method and know almost exactly what it does. It's a lot of work; you have to examine:
- the instructions inside the method
- the arguments to the method
- the instance variables and the methods of the containing class
- the instance variables and methods of the parent classes
- the contracts of any classes you have to be using
It's annoying to do but the lexical structure of the language makes it clear where you have to look. The only exception is when derived classes override methods in the class you're examining. (And this is a problem with every class-based OO language out there.) If the method is "abstract", though, at least you have some indication to look elsewhere.AspectJ messes this up badly, because you can no longer tell what's going on by tracing code. To understand the behavior of a method, you have to do everything you did before, plus know and understand every single Aspect defined for your program, since any of them may change any of:
- The behavior at the beginning or end of your method
- The behavior at any function call in your method
- The parent of the class
Aspect weaving is useful---it makes up for some of the lack of power of Java---but if Grady Booch's hype machine is successful, he'll sell a lot of books, people will use a lot of Aspects, and no one will be able to tell what is going on in their programs.