一.命令模式（Command Pattern）的概述
1.讲一个请求封装成一个对象，从而让用户使用不同的请求将客户点参数化
2.对请求排队或者记录请求日志，以及支持撤销操作
3.优点：降低耦合度，程序扩展性更好
二.命令模式-应用场景
当需要将方法调用包装成一个对象，以及延时方法调用，或者让其他组件在对其内部实现细节不了解的情况下进行调用的时候可以使用命令模式
场景1.应用程序支持撤销和恢复
场景2.记录请求日志，当系统故障时这些命令可以重新被执行
场景3.想用对象参数化一个动作以执行操作，并且用不同的命令对抗来替换回调函数
三.设计命令模式的步骤
1.确定框架模式
2.分析角色
每一种设计模式里面都会有角色划分，不同场景下角色不同，有时一个类可能担当多个角色
如：USer类（具体产品类，抽象产品类），在架构设计中存在多种角色划分
3.分析单个角色类结构
4.分析单个角色意义（如子类意义所在）
5.分析模块
6.最后分析性能优化
概念就说这么多，下面上代码分析具体案例
例：一个魂斗罗游戏人物的操作，有上下左右跳开枪等等操作
第一步：创建一个协议（抽象命令接口）用来进行操作魂斗罗人物的操作（以后如果扩展更多操作，协议都不用改变，这就是扩展性好）
第二步：创建具体的魂斗罗人物操作命令，每个操作都是一个模型并且遵循上一步的协议，每个模型里对应的都是操作的具体实现
第三步：创建一个接收者模型，用来接收来自上一步的具体的操作命令
第四步：实现第二步与第三步的命令对接
第五步：创建请求者（命令管理器），所有的命令请求都通过该模型进行发送
但是大家不觉得这样的写法很累赘吗！而且扩展性很差，比如还有个“跳”的操作我没写，如果加上的话，这个初始化方法就要重写，这样违背了我们的扩展性好的特点，所以我们需要改变下
but but but 重要的事说三遍，这个优化方法我这次不告诉你们，大家可以想想，下一篇我在说（手动滑稽）
言归正传
以上几步操作基本上就完成了魂斗罗操作的命令模式了
接下来验证下
看下打印结果
结果是对的，这就证明我们的命令模式是成功的
最后可能有人要问了
明明是一个简单的逻辑，为什么创建这么多类，搞的这么复杂，我想说的是，当你有这种想法的时候你就还有的学呢，当然我自己也有的学
什么叫设计模式？
设计模式是归类于架构设计的，当你一个架构搭建的越好，设计模式设计的越完善，以后对工程的代码更新迭代就越轻松，反之，你会觉得越来越难受
最后附上demo的地址，demo里还有撤销删除操作，大家可以看下
最终我还是把优化的demo贴出来吧，这个优化的方案也只是加了一个管理者，大家可以看下
下面这个链接是命令模式的变种，也是优化上面的demo的：iOS设计模式之命令模式（2.动态命令） - 简书
网友评论