Undo和Redo是很酷、很神奇、很有用的功能!
如果要求你在你的 软件 中实现Undo和Redo,你会怎样考虑呢?
常见的 软件设计 如下:
用户通过点击菜单、按钮等去激活一些功能。
菜单、按钮中的代码可能是:
button1_Click()
{
XXClass obj = new XXClass();
obj.XXMethod();
}
设计分析:
调用某类某方法的代码,一般直接写在Client中的,代码写法类似上文所述的那样。这样调用某命令的代码,与被调用者就“绑死”了,Undo和Redo更加难实现了。
“撤销”怎样做呢?为每个FunctionX的每个方法写一个对应的Undo方法吗?另外如何才能记住先后调用了什么类的什么方法呢?
我们看看命令模式的 类图 :
说明:
1.Client不直接调用某某类的某某方法,而是将这些调用全部包装在ICommand中,Client只管调用ICommand的Execute()、Undo()。
2.具体实现各种功能的Function类不需要做任何修改,它们唯一变化的地方就是需要被包装进一个一个Command中。
如果要求你在你的 软件 中实现Undo和Redo,你会怎样考虑呢?
常见的 软件设计 如下:
用户通过点击菜单、按钮等去激活一些功能。
菜单、按钮中的代码可能是:
button1_Click()
{
XXClass obj = new XXClass();
obj.XXMethod();
}
设计分析:
调用某类某方法的代码,一般直接写在Client中的,代码写法类似上文所述的那样。这样调用某命令的代码,与被调用者就“绑死”了,Undo和Redo更加难实现了。
“撤销”怎样做呢?为每个FunctionX的每个方法写一个对应的Undo方法吗?另外如何才能记住先后调用了什么类的什么方法呢?
我们看看命令模式的 类图 :
说明:
1.Client不直接调用某某类的某某方法,而是将这些调用全部包装在ICommand中,Client只管调用ICommand的Execute()、Undo()。
2.具体实现各种功能的Function类不需要做任何修改,它们唯一变化的地方就是需要被包装进一个一个Command中。
3.命令模式可将功能调用者与功能实现者分离,可实现Redo和Undo、命令执行队列等特性。
请看下一文……
作者:张传波
创新工场创业课堂(敏捷课程)讲师
软件研发管理资深顾问
CMMI首席专家
《火球——UML大战需求分析》作者