我有一个事件驱动的架构,其中A正在等待来自B的更改,B正在等待来自C的更改,而C正在等待来自A的更改,形成一个循环。
现在,如果B发生更改,则A向C触发事件,C触发到B,B触发到A,A触发到C...以此类推。
我现在可以更改我的程序,使其不包含这个循环,但我担心以后可能会陷入一个无法摆脱的困境。在设计基于事件的系统时,如何避免这种情况的发生?
我有一个事件驱动的架构,其中A正在等待来自B的更改,B正在等待来自C的更改,而C正在等待来自A的更改,形成一个循环。
现在,如果B发生更改,则A向C触发事件,C触发到B,B触发到A,A触发到C...以此类推。
我现在可以更改我的程序,使其不包含这个循环,但我担心以后可能会陷入一个无法摆脱的困境。在设计基于事件的系统时,如何避免这种情况的发生?
firingEvent
,并在之后重置它。在设置了firingEvent
的情况下忽略传入的事件。仅在对象状态真正更改时引发事件。
在引发事件时禁止对象状态更改。
绘制出你的依赖关系图,不应该有循环。循环依赖是重新组织代码的好借口。
它们还可能导致死锁,如果你需要另一个原因来避免它们的话。
我认为这是一个好问题。不幸的是,我自己没有完整的答案,但是这篇文章提出了一些好观点:
我不认为答案是避免循环依赖,正如其他人所建议的那样。(好吧,这取决于你对“循环依赖”的定义。)像Java这样的语言会使用接口来在编译时最小化类型之间的循环依赖,这通常是一个好主意。例如,在MVC模式中的视图类不“依赖”于您的应用程序,它只知道名称为ValueChangedListener
、ClickListener
等的接口。但这并不能消除运行时对象之间的循环连接,这就是可能导致事件循环的原因。
循环依赖关系是真的不好。在我理解你的帖子之前,我必须按照A、B和C的术语写下来。我认为你应该摆脱它。如果你把自己逼入一个死角,那么这可能比循环依赖关系带来的问题要好得多。
你肯定也可以避免这种情况。A、B和C之间紧密耦合。我认为你需要重新思考它们的职责。也许有一个共同的D元素会减轻你的设计压力。
另一个想到的方案是架构分层。如果你能将A层放在B层上,并要求任何与B交流的人都必须通过A并沿着各层进行通信,那么你可能会更容易一些。再次强调,我对你的问题了解不多,所以这些只是广泛的建议。
最后一个选择,也是我最不喜欢的,是在三个组件之间传递消息。当访问每个组件时,要求每个组件添加已接收到消息的信息。然后下一个接收消息的组件就会知道谁已经看到了消息。有点像签到表。但是再次强调,最好先尝试其他方法。
祝你好运!