切断依赖关系

在最近的项目中成功的实施了切断依赖关系，感觉不错。

实例1
应用系统对下层驱动的依赖。
背景：应用系统需要下层的驱动，客户也想看到应用的系统的大概样子。而这个应用系统会依赖了下层好几种驱动，而驱动还在开发。
实施：定下了驱动的API，尽快的实现了对这些驱动的模拟。例如：文件系统，配置系统，I/O的模拟数据，RS232通信的数据。找了一个典型的应用流程，把相关的数据全部记录下来。然后就开始模拟驱动的数据返回。
结果：虽然花了好几天做了一个模拟驱动系统，但是应用系统还是在客户要求的时间内做出来了。客户也看到了可以运行的系统。一些稳定的驱动挂接了，而不稳定的驱动都使用了模拟系统。模拟系统将演变成驱动的测试系统。


实例2
应用系统对动态配置的依赖
背景：一个小型的应用容器，依赖2进制的XML 文件。应用容器也是第一次接触，2进制的XML 文件解析也是第一接触。容器的关键是分析清楚动态模型，而2进展解析主要是方案和数据结构。项目时间非常的紧。不可能等待研究清楚了再开始。
实施：设计解析后的生成对象的结构。保证了应用容器只通过接口访问解析后的对象。2进制的XML 文件解析保证生成对象。一个项目被分解成两个子项目。如果有人，就可以同时开始。
结果：应用容器的实现通过工厂方法建立在模拟的解析对象上，很快应用系统开始一步一步的工作了。在应用系统的主要技术问题都解决后，就专心2进制XML文件的解析。不久也开始工作了。虽然现在还没有合并，但是由于接口是统一的，合并从理论上没有问题。（已经合并了成功，基本上没有遇到特别的问题）
实施线路：应用容器的部分实现-->2进制文件的部分解析-->全部解析--->应用容器的全部实现。


DIP （接口颠倒原则）非常的重要，应用系统应尽可能的定义下层服务需求，在实施时设计中间的模拟层（可能叫mock object）对系统开发大有益处。应用系统可以提前测试，毕竟应用系统比下层驱动的业务逻辑要复杂的多。