为什么我不应该使用不可变的 POJO 而不是 JavaBean？

Question

我现在已经实现了一些 Java 应用程序，到目前为止只实现了桌面应用程序。我更喜欢使用不可变对象在应用程序中传递数据，而不是使用带有修改器（setter 和 getter）的对象（也称为 JavaBean）。

但在Java世界中，使用JavaBeans似乎更常见，我不明白为什么我应该使用它们。就个人而言，如果代码只处理不可变对象而不是一直改变状态，那么它看起来会更好。

第 15 项：最小化可变性、有效的 Java 2ed 中也推荐使用不可变对象。

如果我有一个对象 Person 实现为 JavaBean ，它看起来像：

public class Person {
    private String name;
    private Place birthPlace;

    public Person() {}

    public setName(String name) {
        this.name = name;
    }

    public setBirthPlace(Place birthPlace) {
        this.birthPlace = birthPlace;
    }

    public String getName() {
        return name;
    }

    public Place getBirthPlace() {
        return birthPlace;
    }
}

并且相同的 Person 实现为 不可变 > object：

public class Person {
    private final String name;
    private final Place birthPlace;

    public Person(String name, Place birthPlace) {
        this.name = name;
        this.birthPlace = birthPlace;
    }

    public String getName() {
        return name;
    }

    public Place getBirthPlace() {
        return birthPlace;
    }
}

或更接近 C 中的 struct ：

public class Person {
    public final String name;
    public final Place birthPlace;

    public Person(String name, Place birthPlace) {
        this.name = name;
        this.birthPlace = birthPlace;
    }
}

我还可以在不可变对象中使用 getter 来隐藏实现细节。但由于我只将它用作struct，我更喜欢跳过“getters”，并保持简单。

简而言之，我不明白为什么使用 JavaBeans 更好，或者我是否可以并且应该继续使用我的不可变 POJO？

许多 Java 库似乎对 JavaBean 都有更好的支持，但随着时间的推移，对不可变 POJO 的更多支持可能会变得更流行？

Answer 1

首选 JavaBean 当

• 您必须与期望它们的环境进行交互
• 时，您有很多属性，在实例化时执行所有初始化会很不方便，
• 您的状态很昂贵或由于某种原因无法复制，但需要
• 您认为在某些时候 进行突变您可能必须更改属性的访问方式（例如，从存储值转移到计算值、访问授权等）
• 您希望遵守编码标准，这些标准盲目地坚持使用 JavaBeans 更“面向对象” 更

喜欢不可变的 POJO 当

• 您有少量简单的属性
• 您不必与环境交互 假设 JavaBean 约定
• 在克隆对象时很容易（或至少可能）复制状态
• 您根本不打算克隆该
• 对象非常确定您不必像上面那样修改属性的访问方式，
• 您不介意听到关于您的代码如何不够“面向对象”的抱怨（或嘲笑）

Answer 2

令我惊讶的是，Thread 这个词没有出现在本次讨论的任何地方。

不可变类的主要好处之一是，由于没有可变的共享状态，它们本质上更加线程安全。

这不仅使您的编码变得更容易，而且还会带来两个性能优势：

• 减少同步需求。

• 使用final变量的范围更大，可以方便后续的编译器优化。

我真的想转向不可变对象而不是 JavaBean 风格的类。通过 getter 和 setter 暴露对象的内部可能不应该是默认选择。

Answer 3

嗯，这取决于你想做什么。如果您使用持久层，并且从数据库中获取一些行到 POJO 中，并且想要更改属性并将其保存回来，那么使用 JavaBean 样式会更好，特别是如果您有很多属性。

考虑一下您的人，有很多字段，如名字、中间名、姓氏、出生日期、家庭成员、教育、工作、工资等。

而那个人恰好是一位刚刚结婚并接受拥有她的女性姓氏已更改，您需要更新数据库。

如果您使用不可变的 POJO，则获取代表她的 Person 对象，然后创建一个新的 Person 对象，将所有未按原样更改的属性以及新的姓氏传递给该对象，然后保存它。

如果它是一个 Java bean，您只需执行 setLastName() 并保存它。

这是“最小化可变性”而不是“从不使用可变对象”。在某些情况下，可变对象效果更好，您的工作就是决定使对象可变是否更适合您的程序。你不应该总是说“必须使用不可变对象”，而是在开始伤害自己之前看看你可以使多少个类成为不可变的。

Answer 4

总结其他答案，我认为：

• 不变性促进正确性（结构可以通过引用传递，并且您知道错误/恶意客户端不会破坏任何内容）和代码简单性
• 可变性促进同质性 >：Spring 和其他框架创建一个不带参数的对象，设置对象属性，然后瞧。使用同一类提供数据和保存修改也使界面更容易（您不需要 get(id): Client 和 save(MutableClient)，因为 MutableClient 是 MutableClient 的后代 人

如果有一个中间点（创建、设置属性、使不可变），也许框架会鼓励更多不可变的方法，

无论如何，我建议将不可变对象视为“只读 Java Bean”，强调一点，如果您是一个好的 。男孩，不要碰那个危险的 setProperty 方法，一切都会好起来的。

Answer 5

从 Java 7 开始，您可以拥有不可变的 bean，这是两全其美的。在构造函数上使用注释@ConstructorProperties。

public class Person {
    private final String name;
    private final Place birthPlace;

    @ConstructorProperties({"name", "birthPlace"})
    public Person(String name, Place birthPlace) {
        this.name = name;
        this.birthPlace = birthPlace;
    }

    public String getName() {
        return name;
    }

    public Place getBirthPlace() {
        return birthPlace;
    }
}

Answer 6

老实说，我认为不可变的对象不会那么受欢迎。

我确实看到了这些优点，但是像 Hibernate 和 Spring 这样的框架目前非常流行（并且也有充分的理由），并且它们确实与 bean 配合得最好。

因此，我认为不变性并不是坏事，但它肯定会限制您与当前框架的集成选项。

编辑这些评论促使我稍微澄清一下我的答案。

毫无疑问，在某些问题领域，不变性非常有用，并且确实得到了使用。但我认为当前的默认值似乎是可变的，因为这是大多数人所期望的，并且只有在具有明显优势的情况下才是不可变的。

尽管确实可以在 Spring 中使用带有参数的构造函数，但它似乎旨在作为一种将遗留和/或第三方代码与漂亮的全新 Spring 代码一起使用的方式。至少这是我从文档中了解到的。

Answer 7

在 Java 编程方面是不可变的：一旦创建的东西就永远不会改变状态，无论是预期的还是意外的！

该技术在防御性编程中非常有用，其中另一个实体无法引起状态变化。

您不希望发生变化的示例：外部系统（单线程或多线程）从您的层获取引用并对对象进行操作并有意或无意地更改它。现在它可以是 POJO、集合或对象引用，并且您不希望对其进行更改或者希望保护数据。您肯定会让对象不可变作为防御技术

您期望更改的示例：实际上不需要不变性，因为它会阻碍正确的编程过程。