是否将事件链接视为良好做法？

我时不时遇到一些场景，在这些场景中，触发事件之前需要满足一些复杂的条件。此外，大多数侦听器还会运行其他检查以确定操作过程。这让我开始思考，更好的解决方案是否是考虑较小的事件并使它们彼此触发。

链接事件将使我以后可以用相当少的精力（可能违反YAGNI？）来编织任何其他侦听器。我的代码将由简单易懂的元素组成，其他人应该不难理解。

但是，此解决方案的可能缺点是，如果链中发生某些错误（例如，由于人为错误导致的错误事件触发），则很难捕获该错误。

被事件链接是个好主意^TM？如果不是，那么使事件相关代码变得混乱的替代方法是什么？

事件链接是个好主意吗？

在您使用它之前，这似乎是一个好主意。

没有某种类型的对顺序的隐式依赖，很难建立级联事件。很难设置它们而不会因无限循环和偶发的内存泄漏而引起问题。由于需要知道在何处附加和在何处层叠的事件引起的耦合，它们使类设计更加困难。

而且，他们非常难以调试和推理代码。

现在，有时可以在相对有限的场景中使用它们，其中代码的结构限制了其中一些问题。在UI中，级联事件可用于触发层次结构，因为该层次结构有助于限制所有权和循环问题。

不过，如今，我发现在构造器中接受此类可扩展行为的委托的可能性要比让任意行为在运行时闭锁的可能性高得多。

事件链接是一个好主意

• 通常适合您的情况。一个简单的示例是用户的UI动作触发其他视觉事件。
• 每个事件都是独立且可管理的。您不希望解决方案变得过于繁琐。
• 控制流程易于遵循。它需要在平台上以易于开发人员使用的语言来实现。如果您需要跟踪“魔术”方法以跟踪正在发生的事情，那么您就走错了路。

在开始构建系统之前，仔细考虑解决方案并概括一些内容非常重要。例如，使用OO语言，您应该有一个基本接口或抽象类作为所有事件的基础。该类应包含日志记录/调试之类的内容。您可能还需要通用的事件管理类，以优雅地处理故障。

从曾经花了几天时间来追踪与事件链相关的错误的人的角度来讲，这是一个非常糟糕的主意。您正在隐藏控制流（如您所述），这会使调试成为一场噩梦。当有人添加一些错误处理代码以重置控件时，我出现了这种情况。这导致了一系列onPropertyChange处理程序，这些处理程序最终刷新了具有错误处理程序的控件，导致该控件再次重置了另一个控件，依此类推。基本上，UI会简单地将CPU锁定为100％。

如果您有某种方法可以防止针对同一根事件多次触发事件处理程序，那么您或许可以避免这种情况，但是我可以想象您可能需要多个事件处理程序调用的情况。

由于其他人提到的所有原因，很难很好地实现事件链接。

但是，这也是大多数规则引擎的基本前提。JBoss Drools，IBM jRules，PegaSystems，Corticon和FICO Blaze Advisor都是主要的业务规则管理系统（BRMS），允许用户声明根据系统中发生的事件触发的规则。正向链和反向链都是可行且可行的。

Prolog语言及其派生词基于相同的概念。

涉及的算法并不简单，调试可能很麻烦，但是在模型中有很多价值。

一个潜在的缺点是，意外地以循环更新结束很容易。例如A-> B-> C-> A-> B ...

另一种方法是创建负责触发一系列事件的复合事件。这意味着您不应该最终陷入一个循环中，并给您一个捕获错误等的地方。我已经在此方面取得了一些成功，尽管公认没有将它用于任何特别复杂的事情（但！）。