Java

I Hate Interceptors

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?

Standard

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s