While we’re on the subject of useful refactorings, I’d like to describe how using an Intercepting Filter helped round up and modularise software setup and initialisation tasks. Before the code could get down to business with the framework’s main task, the SGL_MainProcess, (eg booking a hotel room or editing an FAQ, whatever), a certain amount of setup was necessary.
In the previous version, a number of initialisation tasks were assigned to a single init() method in the AppController, then executed procedurally. The disadvantage of this approach was that the tasks were not testable, they were difficult to reorder, and it was prohibitive to insert custom routines into the pipeline.
Enter the Intercepting Filter, which is basically a chain of decorators. The idea is that you have your main process, then you decorate it with n filters or tasks required to get your system correctly initialised beforehand. The code makes the example clearer:
$input = &SGL_RequestRegistry::singleton();
$input->setRequest($req = SGL_Request::singleton());
$process = new SGL_Init(
From Matt Zandstra’s book:
The model is very extensible. We can add new decorators and components very easily. With lots of decorators we can build very flexible structures at runtime. The component class [in our case SGL_MainProcess] can be significantly modified in very many ways without the need to build the totality of the modifications into the class hierarchy.
Here’s the UML: