对于撤销重做实施最佳实践 [英] best practice for Undo Redo implementation

问题描述

我需要实现撤销/重做框架的工作为我的窗口的应用程序（编辑如PowerPoint），什么都要遵循最佳实践，如何将处理我的对象的所有属性更改它的UI反映。

I need to implement Undo/Redo frame work for my window application(editor like powerpoint), what should be the best practice to follow, how would be handle all property changes of my objects and it reflection on UI.

推荐答案

有两个经典的图案使用。首先是用来存储您的完整对象状态的快照 Memento模式。这比命令图案密集或许更多的系统，但它允许回滚非常简单地以一个较旧的快照。你可以在磁盘上存储快照LA公司PaintShop / Photoshop或保留在内存中的不需要持久性更小的物体。你在做什么正是这一模式是专为，所以它应该符合该法案比别人提出的命令模式稍好。

There are two classic patterns to use. The first is the memento pattern which is used to store snapshots of your complete object state. This is perhaps more system intensive than the command pattern, but it allows rollback very simply to an older snapshot. You could store the snapshots on disk a la PaintShop/PhotoShop or keep them in memory for smaller objects that don't require persistence. What you're doing is exactly what this pattern was designed for, so it should fit the bill slightly better than the Command Pattern suggested by others.

此外，附加说明的是，因为它不要求你有倒数的命令以撤消一些先前完成的，这意味着任何潜在的单向函数[如指出，如哈希或加密]平凡使用倒数命令不能被撤销还是可以通过滚动刚刚回到旧的快照很干脆取消。

Also, an additional note is that because it doesn't require you to have reciprocal commands to undo something that was previously done, it means that any potentially one way functions [such as hashing or encryption] which can't be undone trivially using reciprocal commands can still be undone very simply by just rolling back to an older snapshot.

另外，模式这是潜在的资源较少，所以我会承认，在特定的情况下：

Also as pointed out, the command pattern which is potentially less resource intensive, so I will concede that in specific cases where:

• 有一个大的对象状态被持久化和/或


• 有没有破坏性的方法和


• 其中倒数命令可以很平凡用来扭转采取的任何行动

在命令模式的可能的是更好的选择[但不一定，这将取决于形势非常多。在其他情况下，我会用Memento模式。

the command pattern may be a better fit [but not necessarily, it will depend very much on the situation]. In other cases, I would use the memento pattern.

我可能会使用这两者的混搭不要因为我倾向于关心这个事情来在我身后，保持我的代码的开发，以及它是我的道德责任，我的雇主，以使该过程简单和便宜越好。我看到了两种模式很容易成为不适的不可维护的老鼠洞，将是维持昂贵的混搭。

I would probably refrain from using a mashup of the two because I tend to care about the developer that's going to come in behind me and maintain my code as well as it being my ethical responsibility to my employer to make that process as simple and inexpensive as possible. I see a mashup of the two patterns easily becoming an unmaintainable rat hole of discomfort that would be expensive to maintain.

这篇关于对于撤销重做实施最佳实践的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！