流程与实现分开的理解

一. 设计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)

再来一句: 存在"依赖"关系的两个类注意解耦, 但又不是绝对.

自己还是比较理解的, 但是自己表达得一般般, 献丑了