程序猿 自己所擅长的还是码代码 请远离 业务。

                看着运行的结果，小左不禁发出一声冷笑，暗自为自己感到悲哀。仔细的看着代码，小左开始一一分析自己的悲哀。

                1，业务员和自己的耦合度太高，导致每个业务人员都可以直接命令自己，这导致自己心里很不爽。

                2，由于自己本身只是个程序猿，所以自己对公司的业务并不是特别擅长，很难给任务制定优先级，给任务排序，自己所擅长的还是码代码，结果造成的后果就是经常按时完成了一个不重要的任务，但不小心却将很重要的任务向后推迟了，如果业务人员告状，自己可能就要挨批。可是这么多业务人员提问题，到底谁轻谁重，我哪知道。

                3，如果任务堆积过多的时候，自己有时会忘记其中的一个甚至几个，人毕竟精力有限，如果任务多了，难免会出现这种情况，结果有的业务人员就直接告状到老板那里，实在是憋屈。

                4，由于任务是随即产生的，业务人员什么时候想到任务就随时给自己，所以没有一个整体的规划，很容易导致自己加班。        

                “看来，说来说去，还是业务人员跟我太紧密了啊。”小左叹气道。

                由于小左最近在研究设计模式，所以就想到了是不是可以用设计模式来解决自己和业务人员之间的问题。于是小左开始在度娘上面找寻适合的设计模式。

                “有了，命令模式应该是可以解决的，看它的定义好像挺符合的”。电脑前的小左突然一拍大腿，大叫道。

                定义：在软件系统中，“行为请求者”与“行为实现者”通常呈现一种“紧耦合”。但在某些场合，比如要对行为进行“记录、撤销/重做、事务”等处理，这种无法抵御变化的紧耦合是不合适的。在这种情况下，如何将“行为请求者”与“行为实现者”解耦？将一组行为抽象为对象，实现二者之间的松耦合。这就是命令模式（Command Pattern）。

                看着这个定义，小左心中想道：“命令模式中所说的两个角色，不正是我和业务人员吗。业务人员是行为请求者，他们请求我，噢，不，应该说命令我产生编码，修改bug和处理线上问题的行为，而我就去实现或者说执行这些行为。况且，看命令模式的定义，还可以支持记录，我正需要这个记录啊，否则每次任务太多，忘了哪个任务，都要我挨批。”

               于是小左迫不及待的开始研究命令模式的类图，试图从中找到解决的办法。

 

欢迎收藏我的博客：http://blog.csdn.net/i_like_cpp