“交换移动工厂”值得努力吗？

Question

我注意到，对于像Cloudbalancing这样的问题，移动工厂存在以产生移动和交换。 “移动移动”将云进程从一台计算机转移到另一台计算机。 “交换移动”将来自各自计算机的任何两个进程交换。

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

1. A subjectTeacherHour（主题和教师的组合）有 只有Period的子集可以分配给它们。如果Jane在课堂上教了6个小时，那么每个课程有6 subjectTeacherHour个，必须从该课程的30 Period分配Period;与cloudbalance示例不同，进程可以移动到任何计算机的位置。
2. 只有一个subjectTeacherHour可以分配Period（自然）。

它会尝试将subjectTeacherHour置于符合条件的Periods，直到找到最佳组合。

---

赞成

The manual似乎推荐它。

  

...但是，如旅行锦标赛示例所示，如果可以删除   通过使用一系列大动作来实现硬约束，你可以获胜   性能和可扩展性......

     

......`[大动作的版本]评估不那么不可行   解决方案，使其能够超越并超越简单   版本....

     

...使用多个选择器通常是一个好主意，混合精细   粒度移动和课程粒度移动：...

虽然只有一个subjectTeacher可以分配给Period，但解算器必须暂时中断这样的约束，以发现交换两个特定Period分配可以带来更好的解决方案。交换动作“在这两个州之间移除了这堵砖墙”。

因此，互换行动有助于更快地推动更好的解决方案。

缺点

subjectTeacher只有{strong> 的Period个，可以分配给它们。因此，在任何两个subjectTeacher s之间找到相交（常见）小时有点难以（但可以优雅地实现：Good algorithm/technique to find overlapping values from objects' properties?）。

它只会给我一点时间和最佳的收益吗？

我也担心疯狂的互动会导致两种的举动，导致陷入糟糕的解决方案。

Answer 1

交换动作至关重要。

考虑分配给已预订的房间的2门课程。如果不进行交换，就必须打破一个严格的限制，将1个路线移动到冲突的房间，并选择该移动作为步骤（这是不太可能的）。

您可以使用内置通用交换MoveFactory。如果你自己编写，当你将任何一方移动到一个不合格的时期时，可以说交换移动isDoable（）为假。