Claude Montpetit -- Montpetit.net -- en

In 1998, when I was working at Macadamian, we started the development of a system of components used to produce complex collaborative web-based applications. Generic Item components were at the core of this system. Items could be assigned any type of fields (title, description, creation date, etc.) Items could be related to other items through Relation components (writtenBy, submittedBy, complements, etc.) Metadata (components as well) could optionally be defined to describe what items should be made of. Metadata, Relations and Items being components, they could be instantiated at runtime to construct a complete persistent data structure without any knowledge of the underlying data storage.

What made this product (trademarked Syndeo) powerful and unique was the addition of hooks. Hooks are components that can be attached at runtime to Items. Hooks are behaviours and they can be stacked onto items. For example, we used hooks to add workflow in the system so that new items inserted in certain places would be forwarded to a moderator. Security, and logging were also good hook targets.

We started this project after having done a lot of Windows API programming so the idea of Hooks was in fact inspired from MS Windows hooks. There are many technologies that offer features and concepts that are similar to hooks: database triggers, Java portable interceptors, and another one I found very recently: JAspect, an AOP (Aspect Oriented Programming) framework.

While very powerful, hooks, interceptors, or aspects, whichever you prefer, can sometimes cause problem during development. Their dynamic nature makes them harder to debug as opposed to behaviours that are statically encoded in the class' code. What you see is not what you get. Unexpected behaviours can occur if you loose control on the proliferation of interceptors or hooks. But used wisely, they are powerful. I did not try AspectJ yet but I will keep this in mind when I need to implement something across a system, something like error-handling, contract enforcement, distribution concerns, feature variations, context-sensitive behaviour, persistence, testing (from the FAQ).