最近在书店里买到你们的新书《道法自然》。感觉写得非常好，正如李维先生的评价一样，内容丰富，汇集并组织大量的面向对象知识，并且以一个实践项目为主线将这些知识有机的组织，丰富而且有着内在的统一性。非常吸引人，我已经读了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
{
friend class class4;
// ……
};
原文为：即Class3不仅依赖于Class4，而且Class3还是Class4的友元类。
应该是：即Class4不仅依赖于Class3，而且Class4还是Class3的友元类（Class4希望能访问Class3的非公有成员）。
关于依赖倒置原则，我在写《道法自然》时也经过了仔细的思考。下面从几个方面说明一下我的理解：
首先，从理论上说，Robert Martin是这样定义的：依赖于抽象，而不要依赖于具象（参见：《道法自然 3.4.3）。
更为详细的定义是：
- 上层模块不应该依赖于下层模块，它们共同依赖于一个抽象。
- 抽象不能依赖于具象，具象依赖于抽象。
最后，从传统的分层架构模式的要求来说，应该上层使用下层的服务，依赖于下层；而下层决不能使用上层的服务，依赖于上层。而且，从FishGUI的框架层和适配器层来说，确实，框架层会调用适配层，而适配层绝不会调用框架层，适配层仅仅是反向依赖于适配器接口。
上面分析的这几点似乎存在着很大的矛盾。我觉得只要理解了下面的两个要点，就可以完美地把这些矛盾统一起来了。
- 依赖倒置并不是把“上层依赖于下层”转变成“下层依赖于上层”（模块不可能毫无联系，总有一个模块被别人依赖，相互转换依赖关系没有任何意义），而是两者都依赖于一个抽象接口。
- 开闭原则，完全替换原则和依赖倒置原则是对同一个核心原则从不同的视角观察得到的结果。这个核心原则就是我在《道法自然》一书中不断强调的“针对接口编程，而不要针对实现编程”。这些原则属于OOD的范畴，应该在OOD的阶段使用。
当进入面向对象设计阶段，这些OOD原则就能发挥作用了。这时，按照“针对接口编程，而不要针对实现编程”的原则，通过适配器接口的引入，就能很好地消除上层对于下层的依赖。这样的设计也就能很好地符合开闭原则，完全替换原则和依赖倒置原则，所以说，依赖倒置原则并不是真的把依赖反过来，而是解除了层之间的耦合，使它们更容易适应变化的需求。
这时，也不需要强求加入的接口属于哪一层，而是应该由两层的设计人员共同协商解决，设计出对两层都方便的接口。
这就是我在撰写《道法自然》一书时，对依赖倒置原则的一些思考，希望能听到你的想法。通过这样的交流，就能更加深我们对于OO原则的理解，使OO技术在实践中得到更好的应用，这也是我撰写《道法自然》一书最根本的想法。
王咏武 2004年10月25日
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。