Interceptors are a good idea; if you happen to be writing a Servlet or EJB container. In short if you are the complete master of the domain and its data then it is possible to write a generic way to execute a number of classes at certain points in the workflow. Similarly you can use interceptors if your interceptors never execute code in the context of the workflow they are invoked in.

For everything else you just have a function (it is too much to even call it a method) that goes: Interceptor.invoke(String classname, Map data) or worse still Interceptor.invoke(Map context, Map stuff).

It is hard to believe that anyone would ever write something like this without noticing that no-one would ever be able to maintain it without hours of effort scanning through the reflection code, the factory constructors and the underlying database table to find what class is getting called and what method actually implements the desired functionality. It is also hard to credit that the people who used them would not actually have noticed that they had managed to turn an object-orientated language back into a comfortable procedural one. I remain convinced that in fact it is the comfort level of the procedural code that has led to this approach. In which case the only confusing thing is why is easier to deal with C's function pointers and their associated function pointer tables than dealing with these interceptors?