程序猿 JAVA的类图比命令模式的原版类图稍微多了一层关系

                小左看着自己的作品，自言自语道：“虽然这个实际的JAVA类图比命令模式的原版类图稍微多了一层关系，就是ProductManager和Programmer的关联关系，但是其它的可是和命令模式一模一样啊，而且很明显，业务人员（Salesman）和我们程序猿（Programmer）之间没有关联的关系了。”

                “看来我们公司应该招一个产品经理了啊，还得多招几个程序猿，这样我的工作就简单的多了。公司和程序倒是挺相似的，程序是需要多个类之间相互协作，公司也是一样啊，需要每个员工都分工协作，这样就不需要一些人身兼数职了，简直是累死个人啊！”

                “博客今天就先不写了，稍微总结一下，明天好去给小甜甜说一下我今晚的发现，顺便给她讲讲命令模式。这下又可以在她面前露一手了，估计这样下去，她早晚会爱上我啊。啊，哈哈。。”小左又开始YY了。

                不过为了能给小甜甜留一个好印象，小左可是煞费心思啊，这不，他又开始总结起来了。

                “为了减轻自己的负担，我添加了一个产品经理，并且还将任务抽象成类，这样确实解决了我的很多问题，我得稍微总结下。”

                1，程序猿和业务员解耦，不直接打交道。

                2，产品经理分担了程序猿的很多潜在任务，比如制定任务优先级，先做哪个后做哪个。

                3，程序猿不至于忘掉其中一个任务，因为产品经理那有任务列表的。

                4，任务有规划的完成，不至于加班或者说加班太频繁。

               “不过要是给小甜甜解释，这样还不够啊，得专业一点，才好忽悠啊。”小左暗暗的点头道。

                用编程的语言来解释命令模式的使用场景或者说可以解决的问题，就是下面几点。

                1，希望将行为请求者和行为实现者解耦，不直接打交道。

                2，希望分离掉行为请求者一部分的责任，行为请求者只需要将命令发给调用者，不再主动的去让行为实现者产生行为，符合单一职责原则。

                3，希望可以控制执行的命令列表，方便记录，撤销/重做以及事务等功能。

                4，期待可以将请求排队，有序执行。

                5，希望可以将请求组合使用。

http://blog.csdn.net/i_like_cpp/article/details/9206945