聚合和依赖注入的区别

Question

最近我学习了依赖注入设计模式。

class User
{

private $db;

public function __construct(Database $db) 
{
        $this->$db = $db;
}

}

我不禁想知道这是不是我在聚合中学到的相同的东西。如果我错了，请纠正我。 我知道依赖注入和聚合的目标是不同的。是否有什么我忽略的东西？

- Maaz Rehman

---

您的问题已经有了3个好的答案。请在这些答案中的任何一个上发表评论以获得进一步的澄清。 - Chetan Kinger

Answer 1

我不禁想知道我在集合中学到的是否与这个相同。

考虑一个Department类，例如，它具有Professor对象数组作为实例变量。有两种方式可以使用一些Professor对象初始化教授数组。

1.您可以在Department类中的一些不带参数的方法中初始化Professor数组的元素，如professors[0]=new Professor("CK");和professors[1]=new Professor("MK");。 2.您可以提供一个以Professor类型数组作为其参数的构造函数。任何想要实例化Department的类都必须通过构造函数传递Professor对象数组。

聚合:无论您是使用选项1还是选项2来定义Department如何获取其教授，教授将继续存在，即使没有部门(假设教授属于多个部门)，因此无论部门如何获取其教授，都称为聚合。

依赖注入：如果您使用选项2创建Department实例，则将被称为依赖项注入。一个部门需要教授，并且您正在通过从Department类外部提供来满足此依赖关系。

换句话说，聚合是一种可以使用选项1或2(或其他选项，例如从数据库获取教授并在方法中填充Department中的Professor数组)来建模的关系类型。依赖注入是一种设计类的方式，使其依赖项可以从类外部提供。可以建模聚合关系以支持依赖注入，但这并不意味着聚合和依赖注入是相同的东西。

- Chetan Kinger

Answer 2

聚合是对象组合的一种形式。它与依赖注入无关。

另一方面，依赖注入不涉及对象如何关联，而是如何将其他对象（依赖项）注入到特定对象中。依赖项可以是聚合、服务、存储库、验证器、字面量等。

通常，在强类型语言中，依赖项被引入为接口，以避免将对象耦合到实现细节上。相反，在动态类型语言中，约定和强大的文档可以构建良好且紧密耦合的依赖图。

请注意，数据库不能是聚合。并非所有关联都被视为聚合，但您可以考虑注入的依赖项。

无论如何，您的推理中存在一些设计问题：用户不应该依赖于数据库，但数据层/数据映射层将是注入到用户实体中的更好选择，如果您要实现类似于active record pattern的东西。

- Matías Fidemraizer

Answer 3

聚合通常被建模为一对多的关系，而且往往暗示了部分整体语义。由于这些原因，用户数据库通常不被认为是聚合：关系是1:1的，而用户的概念并不一定意味着有一个数据库。

与此相反，常见的聚合示例是汽车及其轮子。存在一对多的关系，并且汽车的概念通常意味着它有轮子。

依赖注入可以被视为创建关系的方式。关系可以是1:1或一对多。它可能暗示某些语义，也可能不暗示。DI的关键特点是用户不控制DB的创建，也不会启动它的创建。

在实践中，聚合关系通常可以通过依赖注入来创建；但这并不意味着这两个概念是等价的。DI可以创建其他类型的关系，而聚合也可以在没有DI的情况下创建。

- jaco0646

Answer 4

聚合是维护对象之间关联的一种方式。在描述如何结构化对象之间的关系时，使用此术语。它是一个领域术语，在现实生活中，对象之间存在相同类型的关系。

依赖注入是管理对象之间依赖关系以实现松耦合的一种方式。相同的技术可以用于聚合。但通常，在聚合中，重点不在于耦合而在于你的对象之间的关系。这个术语也有来自现实生活的类比，但它们大多用于解释什么是控制反转，通常没有对应于你的领域。

- Ihor Burlachenko

Answer 5

我决定添加这些要点。

如果从你的角度考虑，你应该问这个问题，因为聚合和依赖注入可以促进一个实体，这个实体可以放置在其他实体中，也可以独立工作。

但是有一个区别。在聚合中，你正在使用直接对象。即维护状态、生命周期等对象。

例如: 灯泡和房间

灯泡的实例可以放置在房间的实例中。 但不仅仅是房间，一些实例也可以放置在汽车、收音机等实例中。 而且灯泡的实例也可以独立地工作，而不必放置在其他对象的实例中。

但在依赖注入中，我们专注于类级别的交互。这与纯面向对象编程实践有所分歧。实际上，在DI中，我们倾向于将无状态类（工作者类）注入到其他一些类中。虽然它们看起来像对象，但它们实际上只是被注入的无状态类。该类的实例也可以独立存在。DI被广泛用作传统的单例模式的替代方案，因为传统的方式有一些负面影响。

例如：

假设有一个名为StringUtils的无状态工作者类（不是堆满静态方法的apache版本）。它可以注入到称为NounUtils、VerbUtils等的类中。StringUtils的实例也可以存在。

希望您有一个想法。：））

- Supun Wijerathne