我想知道以下情况对于接收回调/事件的“常规” Java应用程序是否通用。这些回调可能由用户输入触发,也可能由其他方式触发,因此它不仅与UI事件有关:
public void handleEvent( @NotNull final SomeEvent e ) {
final boolean process;
synchronized ( this ) {
process = !e.equals(filter);
filter = e;
}
if ( process ) {
...
}
}
基本上在某种复杂的方案下(非常复杂的UI涉及同一模型的多个视图,并且用户可以在不同的屏幕上修改模型(例如在复杂的3D程序中)),我触发了很多事件,并且我注意到可以使用上面的代码段过滤掉重复的事件。如果已经处理了一个事件,并且下一个即将发生的事件与上一个已处理的事件(保存在
filter
参考中)完全相同,则该事件/回调将被忽略。它工作正常。我想知道是否过滤掉重复事件是一种常见技术?
最佳答案
并非总是如此,但通常这可能表明事件级联链中的某些元素未正确检测到它们不需要发送事件。经典的例子是一个bean的setter,即使值没有改变,它也会生成PropertyChangeEvent。
尽管您完成的工作将过滤掉这些事件,但并不能解决可能是根本性的根本问题。
问题是这些“错误”可以组合形成无限循环。扩展上面的bean示例,假设您有一个UI根据该bean字段重置其可编辑值...并且重置UI值也将调用bean setter,因为那里也没有进行正确的重复检查。第一次编辑该值,将发生无限循环。
这些示例在发生时很明显,但是随着通知层次结构变得越来越复杂,跟踪这些事件变得更加困难,并且它们有可能在更间歇的时间发生。
一个好的经验法则是使每个事件生成组件尽可能保守。在这种情况下(heh),您会收到来自您无法控制的组件的通知,并将转发您自己的事件,然后像您设置的过滤器一样的过滤器可能是防止可能的更大扩散的唯一选择问题不仅仅是性能。