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
_______________________________________________
rules-dev mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/rules-dev
