[u][i]这个系列是早前发布在部门wiki上的，引导组里的兄弟入门OOD，希望同样对刚刚走到OOD门前的同学有用。 [/i][/u]
在我们目前的开发模式下－－使用Spring面向接口编程，这个原则给我们的更多是思维方式上的指导。所以在这里只是简单介绍一下这个原则，不举我们系统中的例子说明了。
先解释一下"依赖"这个词的含义，在软件世界里，引用、继承、实现（realization）、方法参数和本地变量引用都是一个对象对另一个对象的依赖，DIP原则告诉我们：
1、高层模块不应该依赖于底层模块，二者都应该依赖于抽象
2、抽象不应该依赖于细节，细节应该依赖于抽象
这个原则中所说的倒置"不仅仅是依赖关系的倒置，它也是接口所有权的倒置"，就是说，客户或者高层模块应该拥有接口，而服务或者底层模块应该实现该接口。按照这种思路，GatewayPayOrderDAO这个接口不应该属于technicalservice层，而应该属于domain层，因为它是domain层需要的一个服务，technicalservice层只是提供了这个服务的实现而已。按照David老师最初的设想，这样的接口应该放在独立的包中，客户和实现都依赖于它。
依赖于具体并不总是危险的，如果这个具体的类/模块是稳定的，就可以依赖于它。
在我们目前的开发模式下－－使用Spring面向接口编程，这个原则给我们的更多是思维方式上的指导。所以在这里只是简单介绍一下这个原则，不举我们系统中的例子说明了。
先解释一下"依赖"这个词的含义，在软件世界里，引用、继承、实现（realization）、方法参数和本地变量引用都是一个对象对另一个对象的依赖，DIP原则告诉我们：
1、高层模块不应该依赖于底层模块，二者都应该依赖于抽象
2、抽象不应该依赖于细节，细节应该依赖于抽象
这个原则中所说的倒置"不仅仅是依赖关系的倒置，它也是接口所有权的倒置"，就是说，客户或者高层模块应该拥有接口，而服务或者底层模块应该实现该接口。按照这种思路，GatewayPayOrderDAO这个接口不应该属于technicalservice层，而应该属于domain层，因为它是domain层需要的一个服务，technicalservice层只是提供了这个服务的实现而已。按照David老师最初的设想，这样的接口应该放在独立的包中，客户和实现都依赖于它。
依赖于具体并不总是危险的，如果这个具体的类/模块是稳定的，就可以依赖于它。
扫一扫
730
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
