[rules-dev] drools-solver-localsearch lifecycle design issues

I can't seem to decide on a good lifecycle design for drools-solver-localsearch So I was hoping to tap into you guys's experience in doing such things. You can find a uml diagram here: https://taseree.svn.sourceforge.net/svnroot/taseree/trunk/src/uml/localse... Most concepts are explained in my previous blog: http://blog.athico.com/2007/06/local-search-101.html There is however a new concept of a "Forager", which simple gathers all accepted moves and sorts them (for example on max score). I have different Selector, Accepter, Forager and Finish implementations, of which some have needs: - SolutionTabuAccepter needs the Random singleton (this needs to be a singleton because it's seeded for predicable results) - SolutionTabuAccepter needs the stepSolution after it has been decided. - SimulatedAnnealingAccepter needs finish.calculateTimeGradient() (but this should be cached over all move iterations in a single step.) - UnimprovedStepCountFinish needs bestSolutionRecaller.getBestSolutionStepIndex() - ... With which scenario do I deal best with this? scenario 1) chaining till we find it: - SolutionTabuAccepter: decider.getLocalSearchSolver().getRandom().nextDouble(); - UnimprovedStepCountFinish: localSearchSolver.getBestSolutionRecaller().getBestSolutionStepIndex(); This is hell for backwards compatible refactors... scenario 2) instanceof on Aware and Lifecyle interfaces: if (accepter implements LocalSearchSolverAware) { ((LocalSearchSolverAware) accepter) .setLocalSearchSolver(localSearchSolver); } This is doing instanceofs... scenario 3) some ServiceLocator pattern and inject it all over the place public interface ServiceLocator { LocalSearchSolver getLocalSearchSolver() Finish getFinish(); ... } This is ugly... Anyone got a better scenario? I was thinking of scenario 2, which would fit in with the fact solver needs a configuration framework anyway... Thanks for helping out this design issue :) -- With kind regards, Geoffrey De Smet