代码中的非正常依赖

前几天收到一个朋友的来信，讨论了一下面向对象实现中经常遇到的问题：在问题域中不存在的依赖关系，在代码实现中却不得不存在。我给出了自己的看法，又觉得不是很有把握，请大家一起来考虑考虑。

******************************* 朋友来信 *******************************

您好！

　　......

　　Robet C.Martin的《UML for Java programmers》（清华大学出版社），书讲到“开放－封闭原则（OCP）”（65页）时举了个例子。

　　图6-4的OCP的违例是Employee类依赖于EmployeeDB。然后作者在图6-5中给出遵守OCP的设计，是Employee依赖于EmployeeDB接口，而EmployeeDB实现那个接口。——这个叙述我明白了。

　　但是，EmployeeDB要实现（持久化Employee的）writeEmployee方法，需要给这个方法传入一个Employee的实例。这样可以说EmployeeDB是依赖于Employee的（如64页图6-2所示）。

　　这样，Employee和EmployeeDB接口之间不就构成了循环依赖了么？

　　即：Employee依赖于EmployeeDB接口；同时EmployeeDB接口中的方法需要Employee实例作为参数或返回值（EmployeeDB依赖于Employee）。而书前面已经提到循环依赖是不好的设计。

　　我现在不清楚：

　　１）我对图6-5的理解是否正确？

　　２）是不是真的构成了循环依赖？

************************** 我的回复 ***************************************

你好！

        抱歉，我在外地，手边没有这本书，只能根据你的问题做一些猜测，如果有错误的话，请原谅。

 

        首先你要区分“has-a”和“uses”两个关系。这两种关系很接近，所以他们之间的关系很微妙。表现在程序里，has-a是指一个对象中内置一个指向另一个对象的引用作为数据成员，而uses关系，使指对象中的一个或多个方法需要指向另一个对象的引用作为参数传入，然后调用该对象的一些方法来完成任务。不管是has-a还是uses，无非都是需要享用对方提供的服务。可以认为，has-a关系是比较稳定的uses关系，而uses关系则是比较偶然的has关系。

 

        然后我们来谈依赖。一个对象要享用另一个对象的服务，就可以说形成了依赖关系。只不过，has-a的依赖比较稳定持久一些，uses的依赖比较偶然一些，所以可以认为，has-a的依赖比uses的依赖“强度”要大一些。

 

        原则上，面向对象设计中应当尽力避免发生对具体对象的依赖，所有的依赖关系最好都是依赖于接口的。从这个意义上来说，最理想的情况是，一个对象中只能包含指向interface的引用，而所有的方法中的参数类型都是interface。

 

        这是理想状况。现实世界里这样做是要累死人的，而且也根本不需要在任何场合不由分说地都搞松耦合。相反，应用程序整体上应当划分为几个尺度适当的模块，模块之间固然应当松耦合，而模块内部就没有必要再搞得松松垮垮的。一般只在应用程序的模块边界上用interface抽象。

 

        当两个对象之间发生所谓循环依赖的时候，通过具体分析，你可以得到一个整体的概念，即究竟哪个对象是client，那个对象是server。比如在你举的例子里，Employee显然是domain中有的实体，而EmployeeDB完全是与domain无关的东西，使为了支持计算而不得不存在的东西。很明显，Employee是client，EmployeeDB是server，是给Employee提供支持服务的。所以在应用领域里，没有循环依赖，而是单向依赖关系。

 

        问题在于，当我们编程实现时，本来是单向依赖的关系，在代码中却出现一种相互依赖的关系。Employee一定要依赖EmployeeDB来进行持久化，这个依赖关系是固有的。而EmployeeDB中的某个方法一定需要Employee对象作为参数，这种依赖关系是偶发的。在这种时候，我们用比较强的依赖关系，也就是has-a来描述固有的那个依赖关系，并且让这个关系依赖于interface而不是具体对象，而用比较弱的依赖关系，也就是uses来描述偶发依赖关系，这是比较合乎逻辑的。你可以这样理解，Employee对于EmployeeDB的依赖，是对象级别的，而EmployeeDB对Employee的依赖，只是个别方法级别上的。故此我们可以说在对象级别上，EmployeeDB并不依赖于Employee，两者的相互关系呈现一种不对称性，而这种不对称性在逻辑上恰恰符合应用域的分析结果。

 

        当然，具体到这个例子，我看问题好解决，让writeEmployee方法接受一个byte[]参数，而让粘结代码负责将Employee实例序列化成byte[]，然后传入writeEmployee方法就可以了。但是其它很多情况恐怕就没这么容易。比如，如果writeEmployee方法除了要写入字节流之外，还需要给被写入的Employee对象打个记号，怎么办？还是只能传引用进去。上面讲的是大道理，实践中还是存在一个逐渐调试的过程。也许你发现出于实用考虑，做一个IEmployee接口也很不错，那就这么办。一切以好用为准。

 

         这个问题也不仅仅是面向对象中的问题，在很多地方都有这个问题：分析上不存在的依赖在代码里是存在的；概念上不需要知道的东西，到了具体代码里就不得不知道。我还是觉得，这些问题大概只有反复实践能够最终认识清楚，良好的、合理的接口设计恐怕只能够是重构出来的，没有什么绝妙的分析技术能够预见到所有的细节问题。

 

        祝好！

 

        孟岩

      2006-8