“交换工厂”值得吗？

Question

我注意到，对于诸如Cloudbalancing之类的问题，存在移动工厂来生成移动和交换。 “移动”将云过程从一台计算机转移到另一台计算机。 “交换移动”交换来自其各自计算机的任何两个进程。

我正在开发一个时间表应用程序。

1. subjectTeacherHour （主题和教师的组合） 只有 Period的一个子集 ，可以将它们分配给它们。 如果Jane在一类教导6小时，有6 subjectTeacherHour s分别具有要被分配一个Period ，从一个可能的30 Period该类的S;不像cloudbalance例如，在处理可以移动到的任何计算机。
2. （自然）只能为一个subjectTeacherHour分配一个Period 。

它将尝试将subjectTeacherHour为合格的Periods ，直到找到最佳组合。

---

优点

该手册似乎推荐它。

...但是，正如旅行比赛示例所证明的，如果您可以通过使用某些大动作来消除硬约束，那么您可以赢得性能和可伸缩性...

... [大动作版本]评估了许多不太可行的解决方案，这使其能够胜过简单版本并超越其规模。

...通常，最好使用多个选择器，将细粒度的动作与粗粒度的动作混合：...

虽然可能仅将一个subjectTeacher分配给Period ，但求解器必须暂时打破此约束，以发现交换两个特定的Period分配会导致更好的解决方案。 在这两个状态之间的调动动作“移开了这堵砖墙”。

因此，调剂举动可以帮助更快地找到更好的解决方案 。

缺点

subjectTeacher 仅具有 Period的子集 ，可以将其分配给他们。 因此，找到任意两个subjectTeacher之间的相交（公共）小时有些困难 （但可以用一种优雅的方式实现： 从对象属性中找到重叠值的良好算法/技术？ ）。

会不会只给我一点时间和最优的收益？

我还担心可能会有两种动作引起疯狂的交互 ，从而导致解决方案陷入困境。

Answer 1

掉期交易至关重要。

考虑分配给已预订满一间客房的2门课程。 如果不进行交换，则必须打破硬约束才能将1条路线移至冲突的房间并选择该路线作为步骤（这不太可能）。

您可以使用内置的通用交换MoveFactory。 如果您自己编写，则可以在将双方移动到不合格期间时将交换移动isDoable（）设置为false。