Algorithm 对于撤消/重做行为，哪一个是可接受的约定？

假设这是一个处理波形的数学应用程序。用户打开波形文件并对其进行编辑

现在，用户使用应用程序工具箱放大波形放大可能需要很长时间。然后他们撤消它。然后他们再做一次

对于重做，应用程序应该如何运行

替换之前执行并由应用程序内部保存在内存中的放大结果

重新运行耗时的放大程序

这个问题扩展到每个功能

---

谢谢：-）

撤消重做操作通常使用一组命令和最后执行的命令的位置来实现。撤消后，将该位置向后移动一步，而不删除堆栈的最后一个命令（现在是最后一个执行的命令之后的命令）

是否随命令一起存储数据取决于您。但是，在您描述的情况下，要使撤消工作，您需要完全反转上一个命令（您可能无法），或者将上一个状态保留在内存中。因此，在放大后保持下一个状态，在这种特殊情况下，不应该花费任何费用。但是，如果用户不重做该命令，您确实需要正确地放弃它

---

正如@EddieWild在一篇评论中指出的，一个命令可能具有固有的破坏性（因此不可恢复），而允许撤销它（通过保持以前的状态）可能是不可行的，例如因为内存限制。在这种情况下，您应该事先通知用户，返回将是不可能的。

我建议挖掘

CQRS

/

CQS

（许多类似名称）的东西。当您将

命令

与

事件

分开时，它就是一种样式。如果您按照

CQRS

明智地设计应用程序，

undo

/

redo

将成为琐碎的任务。您真的认为撤销后立即重做是一种足够常见的场景，值得考虑吗？似乎是针对非现实用例的过早优化。也就是说，这归结为内存/处理时间的权衡。您可以以保留结果的方式对应用程序进行编码，但如果操作系统指示系统处于内存压力下，则结果将被丢弃（重做需要重新计算）波形消耗了多少内存（通常）？@Eddie我会使用内存映射文件处理波形。我想它是直接作用在磁盘上的。大小不得而知。值得注意的是，如果原始操作是破坏性的，保持以前的状态会消耗太多内存，那么有时“撤消”会在上下文中被禁用（原因是@Nelfeal提到）。