OO is to Vector as Aspect is to ...

When beginning to study of Physics, one typically learns about forces, just as Newton framed the subject. Forces are vectors, so you have to learn some trigonometry and linear algebra. Trajectories have a locally computable flavor about them, in that they are determined by summing up the forces imparting accelerations to particles. For example, the deflection of a ray of light through a prism is given by Snell's Law, which concerns itself only with the place where the light ray hits the glass, not original source or final destination of the beam.

And just when you are comfortable with forces being central to everything, the rug gets pulled out from underneath you.

Physicists after Newton reformulated Physics with energy and action as central players. This requires a bit more mathematical sophistication. So as you get farther in the subject, you have to learn variational calculus. Trajectories are now the solutions to a boundary value problems, and have a more global nature to them. For example, the deflection of a ray of light through a prism is governed by Fermat's Principle of Least Time. Out of a family of admissible trajectories, the one nature chooses is determined by a variational principle.

That's a very different way of thinking about natural phenomena. I wonder whether there's an analogy here to object oriented and aspect oriented programming.

Becoming comfortable with object oriented programming is like learning about vectors and matrices. Objects interact with each other by sending messages changing each other's state. This reminds me of forces imparting accelerations to particles. Direct method calls are like fricative forces, and JMS calls to mind magnetism or electrostatics.

The shift in thinking that's required to embrace aspect oriented programming is like learning about the principle of least action. For want of a better phrase, cross cutting concerns have a more, well, globally principled feel to them.

Consider a problem drawn from my real experiences with a system that makes a number of remote procedure calls. Sometimes, things get bogged down, and it's important to know where the time is getting consumed. The original OO approach was to design a little helper class that callers could use to keep track of how long each RPC took.

MyHelper helper = new MyHelper("rpcMethodA");
rpcMethodA();
helper.done();

The constructor took note of the current time and method name, and then the done method wrote an informative log message recording how long the method took.

But, rather than polluting the biz logic with all this bookkeeping, this problem calls out for an aspect oriented solution. A better approach would be to make an aspect that did the timekeeping and logging, and then advise whatever methods you wanted. In my imagination, this feels like imposing a variational principle on the software.