本文探讨了命令模式的本质，即封装命令并分离发出与执行责任。通过命令模式，系统能更好地解耦请求调用者与接收者，支持命令的存储、传递、组合及撤销操作。
看了大话和Head First上的UML图，不禁的就使我糊涂了。
从网络上来看，也没有一个统一的定论，反观，全都是同样的不知出处的文章被反复粘贴使用。
而从我个人的角度上来讲，还是比较支持大话的。
对于命令模式个人理解，
之前我们需要一个东西干一件事，一个方法直接调用另一个方法，也就实现了。
这样呢，两个方法之间联系比较多，关系比较复杂，如果再有新的需求，需要更改被调用的方法，
可能前一个方法还需要更改。
这不是我们想要的，所以我们现在最好是面向接口、抽象编程。
命令模式的本质是对命令进行封装，将发出命令的责任和执行命令的责任分隔开
命令模式允许请求的一方和接收的一方独立开来，使得请求的一方不必知道接收请求的一方的接口，更不必知道请求是怎样被接收，以及操作是否被执行、何时执行，以及是怎么被执行的。
命令模式使请求本身成为一个对象，这个对象和其他对象一样可以被存储和传递
命令模式的关键在于引入抽象命令接口，且发送者针对抽象命令接口编程，只有实现了抽像命令接口的具体命令才能与接收者关联。
模式优点
降低对象之间的耦合度
新的命令可以很容易的加入到系统中
可以比较容易地设计一个组合命令
调用同一个方法实现不同的功能
适用环境
系统需要将请求调用者和请求接收者解耦，使得调用者和接收者不直接交互
系统需要在不同的时间指定请求、将请求排队和执行请求
系统需要支持命令的撤销（Undo）操作和恢复（Rdeo）操作
系统需要将一组操作组合在一起，即支持宏命令
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
