java – paint应用程序中undo / redo的命令模式
我想在一个小的paint application中实现undo / redo.看起来Command Pattern非常适合使用,但我不确定如何最好地实现它. 据我了解的模式,有必要在每个命令中包含: >用于重做的绘制操作的详细信息(例如,行 – >开始和结束点,自由格式行 – > GeneralPath) 我的理解是,每个命令都需要是“原子的”或自包含的,并具有撤消/重做该操作所需的所有信息. 不幸的是,这需要存储比我最初预期更多的信息.对于一行,我们还必须考虑最初用于绘制它的Color,Stroke和RenderingHints之类的东西.这将我的“简单的小命令”变成了一些东西……在内存中体积更大,并且有更多的样板代码可以生成(每个都是可序列化的bean1). 出于记忆保护的原因(大多数情况下),我想要“欺骗”命令的规范.也许每100次更新都会备份整个绘图区域,但是不存储已更改图像的任何部分,只需为每次新的绘制操作重建最后(最多)100个命令.但是在绘制每个零件之前确保Graphics对象的状态是正确的似乎是有问题的 – 这部分可能需要一条线,但RenderingHints在4个命令之前被更改,Color在之前改变了98个命令,而Stroke仍然是最后227个命令也一样. 追求更高效的内存命令似乎将模式从“原子”方面抛到了窗外.这反过来导致难以确定可能影响渲染的最早命令. 我是不是该: >寻找新的模式? 更新 >“每个都将是一个可序列化的豆”第二个想法,没有.我做了圆顶检查,发现Graphics2D(整齐地封装了绘制时使用的许多参数)不可序列化.此外,BasicStroke是可序列化的,但不存储笔划的粗细.我可以创建许多属性的可序列化版本,但它似乎会产生更多的代码,所以我将放弃该规范.同样.我将只尝试在运行时存储对BufferedImage的引用. 最佳答案
我会坚持使用命令模式,并首先尝试一个天真的解决方案(=最需要内存的).对于某些图形操作,甚至可能需要在命令对象中保留整个图像的副本(例如,考虑过滤器).这在专业图像编辑应用程序中也是常见问题,它们通常具有记住的最后命令的存储器或步骤限制.如果内存消耗非常大,您可能会考虑将命令历史中最旧的条目交换到文件系统.我认为用户不会介意等待一段时间才能完成更改.
(编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |