POJO 类详解 | Baeldung中文网

1. 概述

本文将深入探讨 “Plain Old Java Object”（简称 POJO） 的定义和实际意义。

我们会对比 POJO 与 JavaBean 的区别，并分析将 POJO 升级为 JavaBean 带来的便利性。对于有经验的开发者来说，理解这两者的边界能帮你避开不少框架集成时的“坑”。

2. 什么是 POJO

2.1 POJO 的定义

一个 POJO 就是一个普通的 Java 类，它不依赖任何特定框架，也没有强制的命名规范或继承要求。

✅ 关键特征：

不需要实现特定接口
不需要继承指定父类
属性和方法命名自由

来看一个典型的 EmployeePojo 示例：

public class EmployeePojo {

    public String firstName;
    public String lastName;
    private LocalDate startDate;

    public EmployeePojo(String firstName, String lastName, LocalDate startDate) {
        this.firstName = firstName;
        this.lastName = lastName;
        this.startDate = startDate;
    }

    public String name() {
        return this.firstName + " " + this.lastName;
    }

    public LocalDate getStart() {
        return this.startDate;
    }
}

这个类可以在任意 Java 程序中使用，因为它完全脱离框架束缚。

⚠️ 但问题也出在这“自由”上：我们没有遵循统一的构造、访问或修改状态的规范。

这会带来两个实际问题：

可读性差：其他开发者需要花时间理解如何正确使用这个类
框架不友好：很多框架依赖“约定优于配置”，无法自动识别这类类的属性结构

下面我们通过反射来验证这一点。

2.2 使用反射操作 POJO

为了测试属性发现能力，我们引入 Apache 的 commons-beanutils 库：

<dependency>
    <groupId>commons-beanutils</groupId>
    <artifactId>commons-beanutils</artifactId>
    <version>1.9.4</version>
</dependency>

然后尝试获取 EmployeePojo 的所有属性名：

List<String> propertyNames =
  PropertyUtils.getPropertyDescriptors(EmployeePojo.class).stream()
    .map(PropertyDescriptor::getDisplayName)
    .collect(Collectors.toList());

输出结果却是：

[start]

❌ 只识别出了 start，而 firstName 和 lastName 完全被忽略！

原因很简单：PropertyUtils 是基于 JavaBean 命名规范工作的，它只认 getXxx() 和 setXxx() 形式的 getter/setter。而我们的 getStart() 虽然符合规范，但 firstName 和 lastName 是 public 字段，并非通过 getter 暴露。

同样的问题也会出现在 Jackson、Spring Data 等主流框架中 —— 它们对“非标准”POJO 的处理往往不如预期。

3. JavaBean 规范

3.1 JavaBean 是什么

JavaBean 本质上仍然是 POJO，但它遵守一套严格的编码规范，以便被框架广泛支持。

✅ 标准 JavaBean 需满足以下条件：

所有属性私有化（private）
提供公共的 getter 和 setter 方法，遵循 getXxx() / setXxx() 命名规范（布尔类型可用 isXxx()）
包含一个无参构造函数（用于反射实例化，如反序列化）
实现 Serializable 接口（可选但推荐）

这些约定让框架可以通过反射自动发现属性、进行映射、序列化等操作。

3.2 将 EmployeePojo 改造成 JavaBean

我们来把之前的 EmployeePojo 改造成标准的 JavaBean：

public class EmployeeBean implements Serializable {

    private static final long serialVersionUID = -3760445487636086034L;
    private String firstName;
    private String lastName;
    private LocalDate startDate;

    public EmployeeBean() {
    }

    public EmployeeBean(String firstName, String lastName, LocalDate startDate) {
        this.firstName = firstName;
        this.lastName = lastName;
        this.startDate = startDate;
    }

    public String getFirstName() {
        return firstName;
    }

    public void setFirstName(String firstName) {
        this.firstName = firstName;
    }

    public String getLastName() {
        return lastName;
    }

    public void setLastName(String lastName) {
        this.lastName = lastName;
    }

    public LocalDate getStartDate() {
        return startDate;
    }

    public void setStartDate(LocalDate startDate) {
        this.startDate = startDate;
    }
}

改动虽小，但意义重大。

3.3 反射再测试：JavaBean 的优势

再次使用 PropertyUtils 获取属性列表：

List<String> propertyNames =
  PropertyUtils.getPropertyDescriptors(EmployeeBean.class).stream()
    .map(PropertyDescriptor::getDisplayName)
    .collect(Collectors.toList());

输出结果变为：

[firstName, lastName, startDate]

✅ 成功识别全部三个属性！

这就是 JavaBean 的威力 —— 通过命名规范换取框架级支持。像 Jackson、Hibernate、Spring BeanWrapper 等都依赖这套机制自动工作。

4. 使用 JavaBean 的权衡

虽然 JavaBean 在框架集成上表现优异，但它并非银弹。使用时需注意以下几个“代价”：

⚠️ 可变性问题（Mutability）
JavaBean 天然支持 setter，导致对象可变。在并发场景下容易引发状态不一致，也不利于函数式编程风格。

⚠️ 样板代码泛滥（Boilerplate）
每个字段都要写 getter/setter，即使只是简单封装。虽然 Lombok 可以缓解（@Data 或 @Getter/@Setter），但本质上问题仍在。

⚠️ 强制无参构造函数的风险
为了满足反射创建需求，必须提供无参构造函数。这可能导致对象处于“不完整状态”，破坏了构造时的业务校验逻辑。

例如，我们本希望 firstName 和 lastName 必须存在，但现在可以通过 new EmployeeBean() 创建一个空对象，埋下空指针隐患。

💡 小贴士：现代框架如 Jackson、MapStruct、Record（Java 14+）已开始支持更灵活的构造方式，不再强求 JavaBean 模式。

5. 总结

POJO 是最基础的 Java 对象形式，自由但难被框架自动识别
JavaBean 是 POJO 的一种规范化子集，通过命名约定换取框架兼容性
多数主流库（如 Jackson、Hibernate）依赖 JavaBean 规范进行属性发现
使用 JavaBean 需权衡可变性、代码冗余和构造安全等问题

在实际开发中，建议：

✅ 对需要序列化、ORM 映射、配置绑定的类，优先采用 JavaBean 规范
✅ 考虑使用 Lombok 减少样板代码
✅ 新项目可评估 Java Record 或 Builder 模式作为替代方案

示例代码已整理至 GitHub：https://github.com/baeldung/core-java-modules/tree/master/core-java-lang-2

Persistence

REST

Security