我认为,我理解“Bean”是一个具有财产和getters/setter的Java-class。据我所知,它相当于C结构。这是真的吗?
此外,JavaBean和常规类之间是否存在真正的语法差异?是否有特殊定义或接口?
基本上,为什么有一个术语?
Serializable接口是什么意思?
我认为,我理解“Bean”是一个具有财产和getters/setter的Java-class。据我所知,它相当于C结构。这是真的吗?
此外,JavaBean和常规类之间是否存在真正的语法差异?是否有特殊定义或接口?
基本上,为什么有一个术语?
Serializable接口是什么意思?
当前回答
JavaBeans是遵循极其简单的编码约定的Java类。你所要做的就是
实现java.io.Serializable接口-保存对象使用公共空参数构造函数-实例化对象提供公共getter/setter方法,以获取和设置私有变量(财产)的值。
其他回答
它们是可序列化的,具有零参数构造函数,并允许使用getter和setter方法访问财产。命名“Bean”是为了包含这个标准,它旨在为Java创建可重用的软件组件。根据维基百科。
构成应用程序主干并由SpringIoC容器管理的对象称为bean。bean是由Spring IoC容器实例化、组装和管理的对象。否则,bean只是应用程序中许多对象中的一个。根据Spring IoC。
只是关于bean概念的一些背景/更新。许多其他答案实际上都有其原因,但没有那么多原因。
它们是在Java早期作为构建GUI的一部分而发明的。他们遵循的模式很容易被工具拆开,让他们创建一个财产面板,这样您就可以编辑Bean的属性。通常,Bean财产表示屏幕上的控件(想想x、y、宽度、高度、文本…)
您也可以将其视为强类型数据结构。
随着时间的推移,这些工具对于使用相同类型访问的许多工具变得有用(例如,Hibernate将数据结构持久化到数据库)
随着工具的发展,它们更多地转向注释,而不是分离setter/getter名称。现在大多数系统都不需要bean,它们可以使用任何带注释财产的普通旧Java对象来告诉它们如何操作它们。
现在我将bean视为带注释的属性球——它们只对它们所携带的注释有用。
豆类本身并不是一种健康的模式。由于它们将所有财产暴露给外部操作,因此它们本质上破坏了封装,并且在使用它们时,有一种趋势(绝非要求),即创建代码以外部操作bean,而不是在bean内创建代码(违反了“不要求对象提供其值,要求对象为您做一些事情”)。使用带有最小getter和无setter的带注释POJO更像是OO还原封装,并且具有不变性的可能性。
顺便说一句,当所有这些事情发生时,有人将这个概念扩展到了名为EnterpriseJavaBeans的东西上。这些是。。。不同的它们非常复杂,以至于许多人觉得他们不理解整个Bean概念,并停止使用这个术语。我想,这就是为什么你通常会听到bean被称为POJO(因为每个Java对象都是POJO,这在技术上是可以的,但当你听到某人说POJO时,他们通常会想到遵循bean模式的东西)
如果您想了解JavaBeans,首先必须了解软件组件。
软件组件
软件组件是运行特定操作的应用程序的一部分。软件组件也可以是服务的一部分。
一个组件是:
已耦合(具有依赖项)Statefull(保存实例变量的状态)不是标准化的,它是为特定的用例而设计的(JavaEEBeans之间的主要区别)在客户端计算机中运行
Java Beans(企业bean)
在Java EE服务器中运行的标准组件包括完成特定服务的不同业务逻辑简化复杂多层分布式系统的开发
JavaBeans更多的是管理大系统的概念。这就是为什么他们需要标准化。
来源
实际上,Beans只是方便使用的对象。序列化它们意味着能够容易地持久化它们(以易于恢复的形式存储)。
现实世界中Beans的典型用法:
简单可重用对象POJO(纯旧Java对象)可视对象Spring使用Beans处理对象(例如,需要在会话中序列化的User对象)EJB(Enterprise Java Beans),更复杂的对象,如JSF Beans(JSF是过时的技术)或JSP Beans
因此,实际上,Bean只是一种约定/标准,它期望Java对象具有某种行为(序列化),并以某种方式对其进行更改(财产的setter)。
如何使用它们,只是你的发明,但我上面列举的最常见的情况。
上面重复了6或7次,说明JavaBeans没有参数构造函数要求。
这是错误的,没有这样的要求,特别是在JavaSpring的上下文中。
描述JavaBeans API的规范版本(1.01)中也没有提到这一要求(https://download.oracle.com/otndocs/jcp/7224-javabeans-1.01-fr-spec-oth-JSpec/). 此外,本规范在以下上下文中仅2次提到“null构造函数”:“每个自定义程序都应有一个空构造函数。”“每个PropertyEditor都应有一个空构造函数。”
因此,该规范的作者似乎不知道或不愿意使用“空构造函数”这一术语,对于JavaBeans本身,仍然没有提及它。