设计模式之命令模式

在2017-01-07有幸参加学习了波波老师【架构师的盛宴（架构设计+设计模式+机器学习）】的半日课程，课上老师讲了很多内容，收获良多，在此非常感谢波波老师。

如果上过课就忘记了，那样太对不起波波老师了，所以硬逼着自己必须要写点东西，趁着有时间，试试呗。

命令模式

这次课程上，老师讲了命令模式，这里我先把PPT的几点列一下：

设计模式的好处

1.简化并加快设计

2.方便开发人员之间的沟通

3.降低风险

4.有助于转到面向对象技术

适用场景

1.我只要结果--可以不要过程，只要结果

2.undo和redo--可以无穷反悔和重做

3.队列请求--可以发出一连串命令，让命令慢慢执行

4.日志请求--可以跟踪任何东西的所作所为，并可以恢复到任意一步

一些设计原则

1.分离变化--找出应用中有可以发生变化的地方，把它们独立出来，不要和那些不需要变化的代码混在一起

2.针对接口编程--针对接口编程，而不是针对实现编程

3.多用组合，少用继承

--继承虽然有强大的重用威力，但很容易继承了不想要的东西

--组合可以发挥重用的作用，并且可以避免继承了不想继承的东西

4.为交互对象之间的松耦合设计而努力

5.依赖抽象，不要依赖具体类

cd绘面板

说明：有一个画图程序，上面有三个按钮，点一下不按钮，分别会画点，线，圆

变化点：

1.画图的类型会变（矩形，椭圆，曲线）

2.按钮对应的画图类型可变

3.宏操作，点线圆组合操作（把单独画点，线，圆的操作组合起来）

这里引用波波老师的几个图哈.

cd绘面板加强版

增加了undo,redo

队列请求

说到队列请求这里，想起了之前做的一个excel导入数据模块

excel的基础数据有好几个类型，相当于不同的命令

当时在处理这一块时，并没有设计好；数据类型是后续新添加，这样导致很多代码重复，代码中变化的地方（数据的不同类型）和数据公用入口的地方混在一起，造成很多if else判断

另外一个是工作流，之前用到的流程控制有公司自己写的(.net有1套，java有2套)，有第三方的（非也大神的fire workflow）

个人想法：

在业务流程初始化时，整个流程有哪些步骤，如何流转，基本上应该是确定的

按照undo,redo的思路，实际业务处理（下一步，撤销，恢复，跳转等简单步骤），应该也可以现吧；不同的步骤操作，相当于不同的命令操作

再复杂一点，如果需要多人同时处理的，在步骤操作前，进行业务条件是否符合判断

日志请求

可以记录所有操作，这又让我想到，业务系统的一个信息维护模块。当我们把信息的所有操作都记录下来，就可以想回滚到哪就回到哪

特别是有些信息需要审批通过才生效的，之前我们是直接把sql语句保存到某个字段，在条件满足后执行，假如sql语句拼装有错，页面就报错了