JavaBeans:我遗漏了什么?

听起来你的思路是对的。不是你错过了JavaBean的要点,而是其他程序员误用了它们。

JavaBeans规范设计用于可视化工具。其思想是,应用程序设计者能够以交互方式配置对象的实例,然后序列化(或生成代码)配置的bean,以便在运行时重构它;其目的是它不会在运行时发生变异。

accessors violate encapsulation

当然,您通常需要配置对象的实例。只是这应该通过某种配置功能来完成。这可能是一个依赖项注入容器、“BeanBox”风格的可视化工具,或者只是读取手工编写的JSON、XML或属性文件。关键是在运行时,这些对象实际上是不可变的;客户端只调用它们的操作,不访问它们的属性。

我喜欢我的物品做同样多的事情 在构造函数中初始化为 突变子。

支持不可变对象是明智的选择。然而,bean的好处是框架/工具/库可以在运行时确定类的属性,而无需实现特定的接口。

例如,假设您有一组Person bean,每个bean都有诸如姓名、年龄、身高等属性。

您可以使用以下代码按名称(例如)对该bean集合进行排序:

Collection<Person> myCollection = // initialise and populate the collection
Comparator nameCompare = new BeanComparator("name");
Collections.sort(myCollection, nameCompare);

这个 BeanComparator 类知道如何从每个对象提取“name”属性,因为遵循Java Beans约定,也就是说,不需要实现接口的“开销”,例如:

interface Nameable {
    public String getName();
    public void setName(String name);
}

public ModelAndView searchUsers(UserSearchCriteria criteria) {
    // implementation omitted
}

maxItems=6 ,Spring框架“知道”它应该调用带有签名的方法

void setMaxItems(int maxItems);

本质上,JavaBeans只是一个简单的约定,它允许在运行时(通常由工具或框架)动态发现类的属性,而事先不方便/不可能知道可能提供的属性。

Builder pattern ,稍微修改构建器以符合JavaBeans标准。因此,如果您需要一个框架功能,要求您的类符合JavaBeans标准,那么您可以使用构建器来代替实际的类。

很久很久以前,我编写了一个Java编辑器,其中包含一个表示文本字符串的简单“数据库”,并且有一个使用bean的“插件体系结构”。您可以通过将一个bean从bean存储箱中拖出并放到编辑器中来向编辑器添加行为;一旦您这样做了,行为(比如,Cntl-T在光标处转置字符)在编辑器中自动可用。bean有一个已知的接口——它们知道如何向容器请求其数据结构和doSomething()方法——容器知道动态加载类文件、实例化对象并设置其对数据库的访问。

顺便说一下,访问器违反封装并不一定是真的;然而,事实上,仅仅因为你有一个成员,你就没有 需要 为其提供get和set方法。JavaBean规范对此有点不清楚;关键是为那些需要在对象“契约”中的东西提供getter和setter。

在内省和反思被添加到语言中并真正理解之后,对这些约定的需求有所减少;在早期Java中,需要有一个约定来查找方法。

bean是以这种方式配置的,因此自动化工具可以创建和修改bean。它们不一定是伟大的设计模式。

这些工具的示例:

Hibernate
JMX