用于绘制应用程序中的撤消/重做的命令模式

Question

我想在一个小的绘图应用程序中实现undo/redo .似乎命令模式非常适合使用,但我不确定如何最好地实现它.

据我了解的模式,有必要在每个命令中包含:

1. 用于重做的绘画操作的详细信息(例如,行 - >开始和结束点,自由格式行 - > GeneralPath)
2. 更改撤消之前组件的状态.在这种情况下,这将是受命令影响的区域的小快照图像.

我的理解是,每个命令都需要是"原子的"或自包含的,并具有撤消/重做该操作所需的所有信息.

不幸的是,这需要存储比我最初预期更多的信息.对于一条线,我们还必须考虑类似的东西Color,Stroke并且RenderingHints最初用于绘制它.这将我的"简单的小命令"变成了一些东西......在内存中更笨重,并且有更多的样板代码可以生成(每个都是可序列化的bean ¹).

出于记忆保护的原因(大多数情况下),我想要"欺骗"命令的规范.也许每100次更新都会备份整个绘图区域,但是不存储已更改图像的任何部分,只需为每次新的绘制操作重建最后(最多)100个命令.但是Graphics在绘制每个零件之前确保对象的状态是正确的似乎是有问题的- 这部分可能需要一条线,但是RenderingHints之前更改了4个命令,之前Color更改了98个命令,而Stroke最后一个保持相同227个命令.

追求更高效的内存命令似乎将模式从"原子"方面抛到了窗外.这反过来导致难以确定可能影响渲染的最早命令.

我是不是该:

• 寻找新的模式？
• 尝试通过调整模式来实现我的特殊需求？
• 将所有这些丢弃在垃圾箱中作为过早优化,并以最简单(并且最耗费内存消耗)的方式对其进行编码,以便遵循定义的命令模式？

更新

1. "每个都是一个可序列化的豆子" 在第二个想法,没有.我做了圆顶检查,发现a Graphics2D(整齐地封装了绘制时使用的许多参数)不可序列化.此外,a BasicStroke 是可序列化的,但不存储笔划的粗细.我可以创建许多属性的可序列化版本,但它似乎会产生更多的代码,所以我将放弃该规范.同样.我只会尝试BufferedImage在运行时存储对引用的引用.

Answer 1

我会坚持使用命令模式并首先尝试一个简单的解决方案（=最耗内存的）。对于某些图形操作，甚至可能需要在命令对象中保留整个图像的副本（例如，考虑过滤器）。这在专业图像编辑应用程序中也是一个常见问题，它们通常对记住的最后命令有内存或步骤限制。如果内存消耗确实很大，您可能会考虑将命令历史记录中最旧的条目交换到文件系统。我认为用户不会介意等待一秒钟直到更改被撤消。