流程与实现分开的理解
一. 设计1
看如下图:
图1.
图1左边的这个流程, 就是需要调用机器人向左走, 向右走. 而可能有很多种机器人(例如有中国机器人, 美国机器人, 德国机器人 ). 本来业务流程与使用哪国机器人是无关的, 流程只管命令机器人完成其动作, 不管机器人是怎么完成的.
所以通过上图中的"机器人通用接口"来隔离业务流程与具体机器人, 这样就避免了业务流程与具体哪国机器人产生过于强烈的联系.
二. 设计2
对比图2的设计.
图2.
图2把"机器人通用接口"去掉了. 流程每走一步要判断是哪一国的机器人. 把业务流程与机器人种类耦合在一起了
三. 对比
1. 如果增加一种机器人, 设计1不需要重新测试流程, 只需增加一种机器人类即可. 而设计2由于在每走一步都要判断哪一国的机器人, 原则上流程需要重新测试.
四. 应用
4.1 其实在开发中遇到很多这种的场景.
例如:
A. 控制打印机打印图形(打印图形的流程是固定的, 或者说打印图形的流程与具体用什么打印机是没有关系的), 此时应该把打印图形的流程与具体打印机的调用解耦(使用接口来隔离).
B. 某个程序过程需要调用某类型的硬件, 这种硬件可能有很多种型号. 而该程序过程与具体的硬件型号是无关的. 解耦吧.
4.2 怎么解耦(就4.1.A和4.1.B).
A. 分析这类硬件有什么公共的特性, 例如打印机 开始打印, 查询是否在打印, 查询状态, 查询缺纸等等.
B. 分析你的业务流程用到了硬件的那些特性, 例如用到了开始打印, 查询缺纸.
C. 通用接口定义的接口就是业务流程中用到的硬件特性, 例如4.2.B中开始打印, 查询缺纸.
D. 业务流程只调用通用接口中的接口.
E. 具体的硬件类实现通用接口.
F. 有时并不是很通用, 那就需要特殊处理.
五. 总结
其实无非就是使用接口来解耦. 就是在软件设计开发中, 对两个在某一方面"没有联系"的事物通过接口来解耦. 如果把两个在某一方面"没有联系"的事物耦合在一起, 就是自找麻烦了.
这里的"没有联系", 通过4.1.A和4.1.B去理解: 业务流程使用硬件, 也就是一种"使用"关系, 类图中说的"依赖"关系(这里有说明http://blog.csdn.net/cay22/article/details/6034635)
再来一句: 存在"依赖"关系的两个类注意解耦, 但又不是绝对.
自己还是比较理解的, 但是自己表达得一般般, 献丑了