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

[Geoffrey De Smet]

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/localsearchsolverDiagram.png
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