command这种方式我非常喜欢,觉得这样把处理和invoke分开了,挺好。
它的想法是,以MFC的UI操作为例。当用户单击一个按钮的时候,以前的做法是直接在OnClickButton中处理这个事情,当然,代码
也是写死到函数中。所以比较麻烦的是在每个button处理中代码都很多,并且当一个button还需要根据外界情况来分别处理的时候,if else会挺烦。有了command就很方便了(想起大洋那个巨复杂,巨乱的VADialog,真是垃圾中的垃圾代码),所有操作都在command对象中处理,而我只要指定这个button和某个command对象绑定即可,一旦触发,即调用command对象的excute,就可完成功能处理。
而且,不同button可以指定不同command。很好,很强大。
但是,这里有一个实现上的问题,command执行的时候往往不能脱离context,所以execute函数必然会使用context中的东西,似乎又没有完全和使用者脱离关系。
command的好处,是可以保持一个command的队列,这样可以取消,删除单个command,或者保存历史记录之类的,很棒。
android中的mediaservice就是采用了这种方式,但它只是对命令进行了封装,实际执行的时候是直接根据command来操作,而非调用command的什么函数。这个似乎和command模式有些偏离。注意,command对象可以封装一个类似上下文的receiver对象,可由这个对象来完成最终的execute
例如
commanda-->execute--->调用receiver--->action。
有点麻烦..
说明下
1 android这个虽然名字叫command,甚至也派生了好些个子类,但它用法类似的是异步调用,更像是消息命令的封装,消息队列...
2 command的模式这个context(receiver)其实非常重要,如果receiver和client是一个东西的话,岂不是代码还是很复杂呀?它到底简化了什么?client端的耦合?