Я пытаюсь реализовать свой собственный MoveListFactory и не знаю, как получить/создать дескрипторы переменных для перемещения, которое я хочу создать. Метод createMoveList (из интерфейса MoveListFactory) принимает единственный аргумент экземпляра моего класса Solution. Из этого я могу получить доступ ко всем переменным планирования, которые мне нужны, чтобы создать ChainSwapMove. Я не уверен, как создать первый аргумент, который требует конструктор ChainSwapMove (например, Collection<GenuineVariableDescriptor>). Пример в документации не проливает свет на этот процесс, поскольку пользовательский ход, используемый в примере NQueens, не требует этой коллекции GenuineVariableDescriptors. Я не сталкивался с примерами того, как кто-то может получить к ним доступ только из информации, содержащейся в объекте Solution.Как вы создаете коллекцию GenuineVariableDescriptors?
1
A
ответ
0
Все, что заканчивается *Descriptor, является очень внутренним API, а не тем классом, который я хочу использовать пользователями. Документы предполагают, что вы создаете свой собственный ход (что действительно сложно построить правильное движение по цепочкам переменных, которые оставляют цепочку в правильном состоянии).
Это, как говорится, вот подсказка: InnerScoreDirector.getSolutionDescriptor().getEntityDescripor(MyCustomer.class).getVariableDescriptor("myPreviousStandstill") ...
'InnerScoreDirector' это просто интерфейс. Как я могу получить конкретный пример, чтобы начать предлагаемую цепочку методов (только из решения)? Ранее я получил дескриптор 'SolutionDescriptor', выполнив' SolutionDescriptor sd = new SolutionDescriptor (OptaInstance.class) ', тогда в моей реальной конструкции движений использовался метод' findGenuineVariableDescriptor', но в этот момент всегда было бы исключение NullPointerException. Это было похоже на то, что он не был инициализирован объектами, которые содержит «OptaInstance». – Alastair
Хмм, MoveListFactory действительно не получает ScoreDirector. Это действительно предполагает, что вы используете свои собственные ходы, вместо повторного использования общих. 'MoveIteractorFactory' действительно получает ScoreDirector, который можно отнести к' InnerScoreDirector', чтобы следовать за белым кроликом по опасной кроличьей дыре ... –
Создание второго экземпляра SolutionDescriptor - плохая идея: слишком много кода полагается на равные проверки, что есть только 1 переменный дескриптор на переменную. –