一个类/包究竟什么时候依赖于另一个？

Question

许多文章/书籍/.. 谈论类或包依赖，很少解释它是什么。我确实找到了一些定义，但它们各不相同，可能并不涵盖所有情况。例如：

• "when one class uses another concrete class within its implementation"（所以不存在对接口的依赖？）
• "when a class uses another as a variable"（继承呢？）
• "if changes to the definition of one element may cause changes to the other"（所以依赖关系是一种传递关系，不仅在包上，而且在类级别上？）
• "the degree to which each program module relies on each one of the other modules"（但你如何定义“依赖”？）

要考虑的其他方面是方法参数、依赖注入、面向方面的编程、泛型。还有其他方面吗？

那么，你能否给出一个（正式的）类之间和包之间的依赖关系的定义，它是万无一失的，并且涵盖了所有这些情况和方面？

Answer 1

如果您在控制反转或依赖注入的上下文中要求依赖，那么您可能对直接相互交互的类感兴趣。这意味着主要是构造函数参数和属性。

在 UML 域图的上下文中，您可能对“真实世界”的依赖关系感兴趣。狗需要食物。那是一种依赖。狗的Bark() 方法返回一个Sound 对象：在UML 域模型中，这不是您感兴趣的东西。狗不依赖声音的存在。

您也可以从哲学角度出发：所有类都相互依赖以实现共同目标；一个（希望）很棒的软件。

所以，总而言之，依赖或耦合不是是或否的问题。这实际上取决于上下文和耦合度（弱，强）。我认为这解释了为什么存在许多不同的依赖定义。

Answer 2

我不久前就该主题写了一篇博文：Understanding Code: Static vs Dynamic Dependencies。基本上，您需要区分 static 依赖项，即编译器在编译时解析的那些，以及 dynamic 依赖项，那些由运行时（JVM或 CLR) 在运行时。

静态依赖通常是由调用静态/最终方法、读/写字段、在类 C 的定义中、由 C 实现接口 I 引起的……所有这些可以在字节码和源代码中明确找到的代码元素之间的关联。

动态依赖通常由在编译时抽象方法调用的所有事物引发，例如对抽象/虚拟方法的调用（多态性）、使用接口类型化的变量或参数（实现类是抽象的）在编译时），还有委托（.NET）或指向函数的指针（C++）。

大多数时候，当您在文献中阅读有关依赖项时，他们都在谈论静态依赖项。

静态依赖项是直接的（意味着不传递）。我在博文中提到的像NDepend 这样的工具也可以从直接静态依赖项 的集合中推断出间接（或称其为传递）静态依赖项。 p>

我在博文中捍卫的观点是，在理解和维护程序时，需要主要关注静态依赖项，即源代码中的静态依赖项。。事实上，抽象设施被用来，嗯......抽象，调用者的实现。这使得源代码更容易开发和维护。然而，在某些情况下，通常是在调试时，需要知道运行时抽象背后的真正含义。

Answer 3

这篇文章是关于静态依赖的——关于动态依赖和区别，请参阅 Patrick Smacchia 的回答。

以一种易于理解的方式：当没有 B 就不能独立使用 A 时，实体（类或包）A 依赖于实体 B。

继承、聚合、组合，都引入了相关实体之间的依赖关系。

所以不存在对接口的依赖？

有，但界面只是胶水。

继承呢？

见上文。

所以依赖不仅是包的传递关系，而且是类级别的传递关系？

是的。

但是你如何定义“依赖”？

见上文“易于理解”的定义。也与您发布的第三个定义有关。

---

更新：

所以如果你在包P1中有接口A，包P2中的类C使用A作为

• 方法参数，或
• 局部变量通过 AOP 编织到 C 中，或者
• class C implements A，或
• class C<E extends A>,

那么 C 依赖于 A 而 P2 依赖于 P1。

但是如果接口 A 是由 B 类和 C 类程序针对接口 A 实现的，并且仅通过依赖注入使用 B，那么 C 仍然（静态！）仅依赖于 A，而不依赖于 B，因为依赖注入点是它不会使粘合组件依赖。