应用错误收集

Java Bean的重点在于系统（特别是GUI Builder）可以检查Java Bean并对其进行配置，而无需事先了解该组件。

虽然这很酷，但它确实只在这种特定情况下有用，而且现在注释会更好用。

因此他们使用绑定属性的原因只是为了支持这种嵌入式GUI组件技术，除非你需要支持反射的构建系统，否则我不会更喜欢它。

对@Mike啮齿动物的回应

假设您允许用户创建一个您将控制的类。这个类有一个“Main”，可以处理几个事件。

通常，您的用户会执行以下操作：

class UserClass(someClass) {
    void mainMethod() {
        someClass.addEventListener(new EventListener() {
            public void eventsHappen(Event e){
                    event1(e)
                }
            }
        }
        someClass.addDifferentEventListener(new DifferentEventListener() {
            public void eventsHappen(DifferentEvent e){
                    event2(e)
                }
            }
        }
    } 

    public void event1(Event e) {
        //java code for event 1
    }
    public void event2(DifferentEvent e) {
        // java code for event 2
    }
}

无论如何，你明白了。当然，您假设此类已在某处注册 - 可能在xml / config文件中。你读它，实例化它并执行mainMethod（由协议或接口定义），它自己注册并开始调用事件处理程序。

现在，您可以通过注释完成相同的操作:(您可能会认识到模式 - 它几乎是Junit如何注释测试。）

class UserClass() {
    @Event1
    void event1Method(Event e) {
        event1's code
    }
    @Event2
    void event2Method(AnotherEvent e) {
        event2's code
    } 
}

这更加直接，并且删除了大部分样板，并且它还消除了对协议或接口的需求，注释更明确地定义和独立。（如果你想检查传递给方法的参数，你实际上甚至不需要事件注释，但是龙就在那个方向上。）

您仍需要在某处注册的类，但这次您只需扫描每个方法以获取事件注释并自行注册。由于只需要几行代码来读取和处理这样的类，为什么要将这种模式限制为单元测试呢？

我发现的另一件事非常简洁，我将这个模式用于“插入”我的Java程序的Groovy类。因为我正在编译给定目录中的所有类，所以扫描注释是微不足道的。对用户的影响是他插入（或编辑）正确注释的groovy文本文件，我的代码立即编译，集成并开始调用他们的事件处理程序。

JavaBeans是一个规范。它将绑定属性定义为其修改导致发出通知的属性，而PropertyChangeEvent是受制裁的通知实体。

因此推定的JavaBeans-spec bean编辑器应该监听PropertyChangeEvents。除了需要使用该规范之外，我自己也不会使用它。

我认为JavaBeans规范在设计时考虑了通用对象处理。例如，将JavaBean放在IDE中并使用可视属性编辑器进行配置。在这种情况下，IDE将使用常规PropertyChangeEvent等。

或者如果你想将相同的命名属性从bean复制到另一个......这是另一种使用bean的例子（BeanUtils类）。

但是，如果你打算做具体的事情，正如Noel Ang所说，我建议强力打字。

为什么使用javabean绑定属性而不是事件？

3 个答案: