关于《道法自然》一书中的“依赖倒置”问题

《道法自然》一书问世后，有不少热心读者发来邮件探讨相关的技术问题。例如，前几天一位读者就“依赖倒置”原则来信指出了《道法自然》中的一个错误。在此，我向那位读者表示真诚的谢意，并将他的来信和王咏武的回复邮件贴在这里，供大家参考。

最近在书店里买到你们的新书《道法自然》。感觉写得非常好，正如李维先生的评价一样，内容丰富，汇集并组织大量的面向对象知识，并且以一个实践项目为主线将这些知识有机的组织，丰富而且有着内在的统一性。非常吸引人，我已经读了100多页。看得很仔细，也思考了很多，所以在读的过程中，我发现了一些小的错误或疑问，在此列出，与您商讨。
　　p.9, line 2 : 一个排字错误：原意 -> 愿意
　　p.140: 箭头应该是由class4 指向 class3, 友元类的依赖关系，我认为画反了。
　　p.113， figure 6-3: 层间依赖关系, 这样的设计我认为不是很好，应该由数据持久化层依赖于 domain logic. 因为domain logic 才是问题域的本质与核心，才是最稳定的。所有的层都依赖于domain 层，domain 层才可以得到最优先的考虑。这样也符合 Robert martin 在《敏捷软件开发》中提出的依赖倒置原则。可以参考《敏捷软件开发》中文版的 page 256 以及chapter 11。也可参考《特征驱动开发方法》中文版的 page 156 的图。
　　p.113, figure 6-4: 层依赖关系似乎也应该倒过来。道理和上一条是一样的。
　　上面两条其实都是 Robert martin 所说的 DIP ( dependancy inversion principle). 它的含义是：

子系统都只依赖于接口，这在你的书中已经提到。
另一个含义，是将接口的定义归属到上层子系统中。也就是说，接口的变化，主要是由上层子系统的变化导致，受下层子系统的影响要小。举例说，就是domain 层拥有 domain 层和数据管理层的接口，而不是数据管理层拥有此接口。这中间的差别非常subtle, 但似乎也很重要。

　　建议：建议将依赖倒置原则加入的您的书中。
　　这些是我的个人看法，提出的目的是与您商讨。
　　也许在这个点上，您是错的。但是瑕不掩瑜，我很庆幸自己买了一本好书。

2004年10月20日

　　多谢您的支持和鼓励，也非常感谢您中肯的意见。
　　P.140关于友元类的描述，确实有一个明显的错误。其中图和代码如下所示：

include “Class4.h”
　　Class3
　　{
　　　　friend class class4;
　　　　// ……
　　};

　　图和代码是统一的，没有错误，但是前面的文字有一个笔误：
　　原文为：即Class3不仅依赖于Class4，而且Class3还是Class4的友元类。
　　应该是：即Class4不仅依赖于Class3，而且Class4还是Class3的友元类（Class4希望能访问Class3的非公有成员）。

　　关于依赖倒置原则，我在写《道法自然》时也经过了仔细的思考。下面从几个方面说明一下我的理解：
　　首先，从理论上说，Robert Martin是这样定义的：依赖于抽象，而不要依赖于具象（参见：《道法自然 3.4.3）。
　　更为详细的定义是：

上层模块不应该依赖于下层模块，它们共同依赖于一个抽象。
抽象不能依赖于具象，具象依赖于抽象。

　　其次，以FishGUI为实例，从实践的角度来看。假设FishGUI框架系统必须要移植到不同的操作系统（如：Windows和Unix），为了使操作系统的变化不影响框架层，就必须抽象出一个操作系统适配器接口，FishGUI框架层中的类只依赖于该接口，而该接口的派生类具体实现到不同操作系统的调用。这个实现是符合依赖倒置原则的。如下图所示：

　　如果我们认为适配器接口类属于框架层，由框架层的开发人员来设计，这个接口就会设计得很适合框架层的开发。但是容易遇到一个问题，当需要移植到另一个新的操作系统时，这个接口可能不适合该操作系统的实现，实现具体的适配器时非常麻烦。这时，两层的依赖关系如下图所示，下层依赖于上层。

　　如果我们认为适配器接口属于适配层，由适配层的开发人员来开发，这个接口就会总结了多种操作系统的特性，使得移植非常方便。但是很容易造成框架层使用的困难。这时，两层的依赖关系如下图所示，上层依赖于下层。

　　这两种不同的选择，在具体的设计中很容易遇到，两种设计得到的结果似乎是相反的，是一个两难的问题。
　　最后，从传统的分层架构模式的要求来说，应该上层使用下层的服务，依赖于下层；而下层决不能使用上层的服务，依赖于上层。而且，从FishGUI的框架层和适配器层来说，确实，框架层会调用适配层，而适配层绝不会调用框架层，适配层仅仅是反向依赖于适配器接口。
　　上面分析的这几点似乎存在着很大的矛盾。我觉得只要理解了下面的两个要点，就可以完美地把这些矛盾统一起来了。

依赖倒置并不是把“上层依赖于下层”转变成“下层依赖于上层”（模块不可能毫无联系，总有一个模块被别人依赖，相互转换依赖关系没有任何意义），而是两者都依赖于一个抽象接口。
开闭原则，完全替换原则和依赖倒置原则是对同一个核心原则从不同的视角观察得到的结果。这个核心原则就是我在《道法自然》一书中不断强调的“针对接口编程，而不要针对实现编程”。这些原则属于OOD的范畴，应该在OOD的阶段使用。

　　根据这两个要点，我觉得对于上面FishGUI的例子，在架构分析阶段，把系统分为框架层和适配层时，不要考虑依赖倒置原则，而是从宏观上看，由于框架层要调用适配层，框架层依赖于适配层，上层依赖于下层。
　　当进入面向对象设计阶段，这些OOD原则就能发挥作用了。这时，按照“针对接口编程，而不要针对实现编程”的原则，通过适配器接口的引入，就能很好地消除上层对于下层的依赖。这样的设计也就能很好地符合开闭原则，完全替换原则和依赖倒置原则，所以说，依赖倒置原则并不是真的把依赖反过来，而是解除了层之间的耦合，使它们更容易适应变化的需求。
　　这时，也不需要强求加入的接口属于哪一层，而是应该由两层的设计人员共同协商解决，设计出对两层都方便的接口。

　　这就是我在撰写《道法自然》一书时，对依赖倒置原则的一些思考，希望能听到你的想法。通过这样的交流，就能更加深我们对于OO原则的理解，使OO技术在实践中得到更好的应用，这也是我撰写《道法自然》一书最根本的想法。

　　王咏武
　　2004年10月25日

关于《道法自然》一书中的“依赖倒置”问题相关推荐

依赖倒置原则——举例说明Java设计模式中的依赖倒置原则
依赖倒置原则--举例说明Java设计模式中的依赖倒置原则一.前言看官方定义二.举例说明 2.1 例子介绍(无聊的可看看,着急的请跳过) 2.2 反例 2.1.1 反例1 (1)类图说明 (2)代 ...
依赖倒置 php,PHP中的依赖倒置原则
PHP 5引入了"类型提示",它使函数和方法能够声明"类型化"参数(对象).对于大多数情况,端口示例应该不是一项大任务,例如从Java到PHP 5. 一个非常简 ...
吐槽依赖倒置原则/DIP
返回目录 1.2.5抛弃依赖倒置原则(正文) ,本文专门吐槽依赖倒置原则(Dependency Inversion Principle.DIP). 1.Robert C. Martin的那篇DIP ...
面向对象设计原则之三--依赖倒置(转)原则
在大多数情况下,这三个设计原则会同时出现,开闭原则是目标,里氏代换原则是基础,依赖倒转原则是手段,它们相辅相成如果说开闭原则是面向对象设计的目标的话,那么依赖倒转原则就是面向对象设计的主要实现机制之 ...
java 依赖倒置_JAVA设计模式之依赖倒转原则
3.1 依赖倒置原则的定义依赖倒置原则(Dependence Inversion Principle,简称DIP)这个名字看着有点别扭,"依赖"还"倒置",这 ...
设计模式-依赖倒置原则
依赖倒置原则 1 依赖倒置原则的定义依赖倒置原则(Dependence Inversion Principle,DIP)这个名字看着有点别扭,"依赖"还"倒置" ...
设计原则——依赖倒置
依赖倒置:要依赖抽象,不要依赖具体类. "倒置"的含义: 如果依赖于具体类去设计.那么画出来的图,高层组件在上面,底层组件在下面,高层组件依赖于底层组件.p138. 如果依赖抽象, ...
从循环引用谈依赖倒置原则
在业务开发中,通常会按照业务或者逻辑将项目分成好几个工程文件以方便重用和模块化,有时候我们分开的两个项目可能存在相互引用的情况,举个例子,比如有两个系统,订单系统和产品系统,订单系统需要从产品系统中了 ...
依赖倒置原则_C#教您一步步摆脱面向过程：依赖倒置
前面有几篇文章,已经教了一些方式或者方法,帮助您摆脱娘胎自带的面向过程编程,从而转为面向对象. 本文讲一下面向对象依赖倒置,使用具体的例子来解释可能好些,网上千篇一律的大多数文字描述,各位估计也不一定 ...

关于《道法自然》一书中的“依赖倒置”问题

关于《道法自然》一书中的“依赖倒置”问题相关推荐

最新文章

热门文章