One will find below the diagram of the CalRecon algorithms at the end of 2004. Apart from the usual historical inconsistencies with class names, I was mainly worrying about the fact that CalClustersAlg has three attributes corresponding to the three concrete classes deriving from IEnergyCorr. The flexibility given by IEnergyCorr is partially frozen by such a predefined number of components.
The first step of refactoring was concerning the clustering classes. It was the easiest door to the package, with much duplicated code. The diagram below illustrates the result. The change appears small as compared to the previous diagram, but this hides many code moved here and there.
Second step was about the energy corrections. As suggested before, main task was to replace the three predefined attributes of CalClustersAlg with a single generic list. This was requiring some work to enforce a real common interface to all tools (there was three predefined attributes because the abstract interface was not appropriate).
While searching for the perfect IEnergyCorr, we finally break the obstacles by using a kind of "proxy" class which were centralizing all the access to the TDS and Gaudi services. We called it the "kernel". As a side effect, centralizing all the Gaudi-like access stuff has considerably reduced the rest of the code and made it clearer. Since kernel was to be shared by all algo-like objects of the package (let's call them "actors"), we made it a Gaudi tool, and we put the code to access this tool in a CalReconActor class to be inherited by all actors. This is what is described below. And this is what is more or less the current state of the code.
I must say I am still not glad enough with this. For example, CalClustersAlg enforce the use of one clusterinfg algorithm as the first one. In the case of a complex reconstruction which alternates cal and tkr steps, it does not make sense to redo the clusters from the beginning each time, does it ? Why not make everything a simple Gaudi algorithm and use a typical simple Gaudi structure such as below ?
For each kind of job, the user can very freely require the best sequence of algorithms in his job options. Whatsoever, I want to keep the kernel made before, which proved very useful, so I would prefer :
If you worry about the fact that a user can also freely and easily makes an irrelevant sequence of actors, there are several answers : you can provide good job options examples, or even enforce the use of predefined job options. We could also go one step further with some classes whose role is to setup the validated sequence of actors. I call them "kits", as shown below. That can be seen as the replacement for "CalClustersAlg". Also, such a top level actor could prove necessary to enforce the right order of initialize calls (we must ensure that the kernel initialize is done before the one of actors which use it).
