UNDO/REDO实现感想[指正有分]
GOOGLE了一把UNDO/REDO实现，发现很多只谈到COMMAND，不是很满意，自己写个实现感想，就放在这里吧。
实际上一个完整UNDO/REDO系统除了COMMAND，还有很多复杂的地方：
1 在每一个COMMAND里面必须保存一个MEMENTO，用来保存COMMAND执行前的状态
1.1 该MEMENTO是用什么方式保存？参数还是内存块？
如是内存块的话？UNDO步数一多，内存是否成为问题？如果是参数的话？如何解析？
1.2 MEMENTO什么时候获取，是自动获取还是用户填入？
1.3 如果是不同类型的COMMAND混合使用，MEMENTO类型是否相同？不同的话，混合使用是否会有问题？
2 COMMANDHISTORY中UI的支持
2.1 如果只支持UNDO/REDO，只需要关心UNDO步数和PRESENTLINE就可以了；
2.2 如果还要支持RESET，必须保存原始状态；
2.3 如果需要支持SLIDER（LIKE PHOTOSHOP），还要考虑UNDO/REDO跳跃及其效率优化问题
3 如何支持无限UNDO/REDO的话
3.1 虚拟内存就成为必须，这部分的管理放在什么地方？
3.2 效率没问题吗？
4 如何方便的替换
4.1 如何可以方便的替换MEMENTO/MEMENTO保存方式/参数及其解析方法？
4.2 如何可以方便的替换UNDO跳跃处理策略？
4.3 如何可以方便的替换虚拟内存管理策略？
关键词：UNDO/REDO， COMMAND， MEMENTO， 设计模式
[解决办法]
我是做图形3D软件开发的,正要做这个部分,一直也在思考.一点想法大家交流.
其实设计模式什么的都不是关键,无非就是用一个栈或者链表表示这个过程,重要的是必须符合项目的实际.
整个UNDO/REDO过程必须保存2部分: 操作命令(COMMAND)和状态(可能就是搂主所说的MEMENTO吧). 命令的保存相对比较容易,
而状态的记录的确相当麻烦.个人感觉,应该是数据和参数混合的形式比较好,不需要教条,只要能正确记录状态的信息就可以.
至于保存在内存还是文件,个人感觉应该在内存开一个缓冲区,记录的数据超过缓冲区的时候再记录到文件中,我仔细思考过,只能如此.当然,还有一个解决方案就是有限次的UNDO/REDO.
状态的记录一定是个难点,例如:像我现在开发的项目,节点都有ID,删除后可能又有新的节点产生,那么UNDO后如何处理这个ID才能合理也是比较头疼的事情.
最后说一下对软件设计模式之类书的看法.这种书不看是不行的,理论的东西必须要有一些,但是千万别教条.而且个人感觉类似软件设计模式的作者很多都没有实际工程的经验,大多是纸上谈兵,如果一切照搬只能自食其果.
[解决办法]
我想补充的是用command只是实现undo/redo的一种方式;(命令容器加上动作的信息,前段时间做一个类似MS的workflow用command实现的)
去年在做一个GUI库的时候,因为仅仅只是个GUI库,没有设计到MVC,界面元素只负责保存自己,我采用的是所有界面元素都是可序列化的(支持文件流和内存流),工程的保存和恢复保存到文件里;每一步改变界面的操作保存到内存里(和保存到文件流的格式一样),undo/redo的时候从内存恢复(相当于恢复工程,所以不保存到内存流而保存到文件流就支持无限次undo/redo);这种方式需要把每一步改变后整个工程都保存再恢复;由于所有界面元素都是可序列化的,这样实现起来也比较方便.
我工作时间不长,才2年多一点,没什么很深刻的经验,就楼主说设计模式,个人的理解是,设计模式只是浮云,设计原则才是王道.从头到尾的看过几本比较经典的设计模式的书了 heard first Design pattern英文版是我的设计模式入门书,后来陆续看了GOF的经典设计模式,看道法自然,后来看敏捷软件开发,再看C++设计新思维泛型编程与设计模式的应用(这本书让我无敌惊叹泛型编程的美妙),可能有些囫囵吞枣,现在基本遇见设计模式能够解决的问题能够立即想到相应的模式...可是这,远远不够,我去年参与的一个GUI库,用不了很多模式,用得更多的是设计原则里的指导思想,现在对OOP只剩下最简单的理解:设计好类,设计好对象之间的交互;
