oop - 依赖注入(inject)系统中的事件往哪个方向发展？

Question

向上还是向下？

我是一个非常注重视觉的人。我将我的应用程序视为一个层次结构，其中顶部是根，底部是叶子。

我还了解到，在 DI 系统中，容器不知道其包含的对象的职责/功能。相反，包含的对象知道它们的上下文，因为注入(inject)了上下文(依赖项)。

UP: (非 DI 方式？)
我的事件是否应该从层次结构的底部 发送并向上冒泡到它们的父级？例如。我的 GUI 中的一个按钮调度了一个 CLICKED 事件，该事件被一个监听容器捕获，该容器通过执行适当的操作来响应。

向下: (DI 方式？)
我的事件是否应该由其子级监听的父级从层次结构的顶部 发送？例如。 --... 好吧，我很难想出这个。我正在考虑为包含的对象分派(dispatch)事件的调解器。

“向上”对我来说似乎很自然，但由于 DI 有一个容器不知道其包含的对象的行为，我不想响应它们的事件。

编辑(澄清):

我意识到让系统的几乎任何部分监听一个事件是可能的，但我想了解 DI 参与者之间的基本关系，以便我可以正确地构造它们。我假设人们通常不会在不考虑结构关系、依赖关系等的情况下散布有关他们程序的事件。

我的问题源于 DI 系统中的责任定位——注入(inject)对象有责任调用注入(inject)器，而注入(inject)器有责任为其依赖对象提供服务(这颠倒了非 DI 范式——因此是同义词比如“控制反转”和“依赖反转”)。这似乎是 DI 的一个非常重要的基本组成部分——责任的转移。我认为调用一个对象的函数或监听它的事件都是依赖另一个对象的例子。当一个对象基于另一个对象定义它自己的行为时，我称之为依赖性，因为一个对象知道另一个对象并且也知道另一个对象做了什么。它在另一个对象的上下文中定义了自己。据我了解，DI的设置使得注入(inject)对象依赖于注入(inject)器，因此注入(inject)对象应该有责任了解注入(inject)器的所有信息。并且了解注入(inject)对象不应该是注入(inject)者的责任。因此，对于监听 CONTAINED 注入(inject)对象上的事件的注入(inject)器，在我看来就像是责任错位，因为这意味着它知道一些关于其内容的事情。

请告诉我这是否错误以及如何错误。

Answer 1

依赖注入(inject)和观察者模式中的角色分配是正交问题。一个对象可以扮演观察者或被观察者的角色，同时可以是组合对象、组合对象、两者或两者都不是。

考虑一个典型的例子，其中一个按钮由一个控件组成。单击该按钮时，它会引发一个 Clicked 事件，该事件由包含的控件响应。在这种情况下，观察对象构成了被观察对象。

现在考虑一个由许多控件组成的屏幕。屏幕可能会引发 Closing 事件，该事件允许组合控件在整个屏幕关闭之前执行自己的清理工作。在这种情况下，被观察对象构成了观察者。

现在考虑一个由按钮和标签组成的屏幕。单击按钮时，将调用标签的 Clear() 方法。在这种情况下，observer 和 observed 都不构成对方，而是由屏幕对象构成。

现在考虑一个屏幕，它引发一个它自己订阅的 Closing 事件(可能确保自己是注册的最终事件处理程序)。当它引发 Closing 事件时，允许任何观察者首先执行他们可能需要的任何操作，然后它会处理自己的事件。在这种情况下，观察者就是被观察者。

依赖注入(inject)涉及对象如何获得其依赖项。注入(inject)给定对象的依赖项可能包含对象想要订阅的事件，或者依赖项可能订阅它正在注入(inject)的对象。两个对象在一个对象注入(inject)另一个对象后如何交互与依赖注入(inject)没有任何关系。

编辑

关于您的澄清部分，我相信我理解您困惑的根源。传统上，对象会创建自己的依赖项。依赖注入(inject)通过将有关如何获取依赖项的知识转移到对象外部来反转获取这些依赖项的责任。但是，依赖注入(inject)不会反转依赖关系。您可能会混淆依赖注入(inject)与 Dependency Inversion Principle . Dependency Inversion Principle 确实颠倒了“高级”和“低级”对象之间的依赖关系，但依赖注入(inject)只关心如何将依赖项提供给给定对象。因此，依赖注入(inject)的使用不会改变对象之间正常交互的方式。如果在使用依赖注入(inject)之前对象 B 订阅了对象 A 引发的事件(反之亦然)，引入依赖注入(inject)将不会改变这一点。