在编写复杂的项目时，培养良好的代码文化至关重要。使用不可变和一致的对象是最重要的对象之一。 您可以忽略这一点并将复杂对象编写为标准对象，但当项目足够大时，它将成为错误的重要来源。 在我之前的 ，我展示了如何提高标准对象的一致性和可靠性。简单来说： 文章中 设置值时添加验证 对每个可为空的字段使用 java.util.Optional 将复杂的突变放置在适当的位置 - 到负责的类本身。 但这些行动不足以制造完全可靠的物体。在本文中，我将展示如何使对象成为不可变对象，并使它们雄辩而有效。 问题 如果我们使用默认构造函数/getters/setters 创建一个简单的可序列化对象，则可以将其设为标准方式。但是让我们假设我们写了一些更复杂的东西。最有可能的是，它在无数地方被使用。 例如，它用于 HashMaps 并且可能用于多线程环境。所以，这似乎不再是一个好主意——以默认方式编写它。  没什么大不了的，线程之间的不一致状态不会让等待很长时间。 打破HashMap 在考虑制作不可变对象时首先想到 是： 的 不要制作setter方法 使所有字段最终 不要将实例共享给可变对象 不允许子类覆盖方法（本文将省略） 但是如何与那种物体相处呢？当我们需要更改它时，我们需要进行复制；如果不每次都复制粘贴代码和逻辑，我们怎么能做好呢？ 关于我们的示例类的几句话 假设我们有帐户。每个帐户都有一个  、  和  。可以通过电子邮件验证帐户。当状态为 时，我们不希望电子邮件被填写。但是当它是 或 时，必须填写电子邮件。  id status email CREATED VERIFIED INACTIVE public enum AccountStatus { CREATED, VERIFIED, INACTIVE } 佳能 实现： Account.java   public class Account { private final String id; private final AccountStatus status; private final String email; public Account(String id, AccountStatus status, String email) { this.id = id; this.status = status; this.email = email; } // equals / hashCode / getters } 假设我们已经创建了一个帐户。然后，在业务逻辑的某个地方，我们需要更改电子邮件。   var account = new Account("some-id", CREATED, null); 我们怎么能做到这一点？默认方式行不通，我们不能使用不可变类的 setter。   account.setEmail("example@example.com");// we can not do that, we have no setters 做到这一点的唯一方法是创建一个新实例并将之前的值放置到构造函数中：   var withEmail = new Account(account.getId(), CREATED, "example@example.com"); 但这不是更改字段值的最佳方式，它会产生大量复制/粘贴，并且 Account 类不负责其一致性。 解决方案 建议的解决方案是提供来自 Account 类的变异方法，并在负责的类中实现复制逻辑。此外，必须为电子邮件字段添加必需的验证和 Optional 用法，这样我们就不会遇到 NPE 或一致性问题。 为了构建一个对象，我使用了“Builder”模式。它非常有名，并且有很多插件可以让您的 IDE 自动生成它。   public class Account { private final String id; private final AccountStatus status; private final Optional<String> email; public Account(Builder builder) { this.id = notEmpty(builder.id); this.status = notNull(builder.status); this.email = checkEmail(builder.email); } public Account verify(String email) { return copy() .status(VERIFIED) .email(of(email)) .build(); } public Account changeEmail(String email) { return copy() .email(of(email)) .build(); } public Account deactivate() { return copy() .status(INACTIVE) .build(); } private Optional<String> checkEmail(Optional<String> email) { isTrue( notNull(email).map(StringUtils::isNotBlank).orElse(false) || this.status.equals(CREATED), "Email must be filled when status %s", this.status ); return email; } public static final class Builder { private String id; private AccountStatus status; private Optional<String> email = empty(); private Builder() { } public static Builder account() { return new Builder(); } public Builder id(String id) { this.id = id; return this; } public Builder status(AccountStatus status) { this.status = status; return this; } public Builder email(Optional<String> email) { this.email = email; return this; } public Account build() { return new Account(this); } } // equals / hashCode / getters } 如您所见，我们的类中有一个私有方法  ，它返回带有精确副本的  。这消除了所有字段的复制粘贴，但是，不能从外部 访问此方法至关重要，因为在外部使用该 Builder 时，我们将失去对状态和一致性的控制。 copy Builder Account.java 以新方式更改帐户 现在，让我们创建一个帐户：   var account = account() .id("example-id") .status(CREATED) .email((empty()) .build(); 当我们需要更改电子邮件时，我们不需要负责创建副本，我们只需从 本身调用一个方法： Account   var withNewEmail = account.changeEmail("new@new.com"); 在单元测试中对此进行演示：   @Test void should_successfully_change_email() { // given var account = account() .id("example-id") .status(VERIFIED) .email(of("old@old.com")) .build(); var newEmail = "new@new.com"; // when var withNewEmail = account.changeEmail(newEmail); // then assertThat(withNewEmail.getId()).isEqualTo(account.getId()); assertThat(withNewEmail.getStatus()).isEqualTo(account.getStatus()); assertThat(withNewEmail.getEmail()).isEqualTo(of(newEmail)); } 为了验证帐户，我们不会创建状态为 的副本和新电子邮件。我们简单地调用方法  ，它不仅会为我们创建一个副本，还会检查电子邮件的有效性。 VERIFIED verify   @Test void should_successfully_verify_account() { // given var created = account() .id("example-id") .status(CREATED) .build(); var email = "example@example.com"; // when var verified = created.verify(email); // then assertThat(verified.getId()).isEqualTo(created.getId()); assertThat(verified.getStatus()).isEqualTo(VERIFIED); assertThat(verified.getEmail().get()).isEqualTo(email); } 结论 与不可变、一致和可靠的对象一起生活是很苛刻的，但如果以适当的方式，它会变得容易得多。 实施时， ： 不要忘记 使所有字段最终 不提供二传手 不共享指向可变对象的链接 不允许子类覆盖方法 提供您班级中的变异方法 实施 在返回 的负责类中 方法，并使用它在您的类中创建新实例。 私人的 Builder copy 通过对值使用验证来保持字段的一致性 将 与可为空的字段一起使用 Optional 您可以在 上找到带有更多单元测试的完整工作示例。 GitHub 由 在 上拍摄的主要照片 Adam Nieścioruk Unsplash

Canon

Oracle

2022 - HackerNoon Contributor of the Year - Backend

2022 - HackerNoon Contributor of the Year - Clean Code

2022 - HackerNoon Contributor of the Year - Debugging

2022 - HackerNoon Contributor of the Year - Java

2022 - HackerNoon Contributor of the Year - Monitoring

2022 - HackerNoon Contributor of the Year - Software Engineering

Nominated for 2022 - HackerNoon Contributor of the Year - Monitoring

Nominated for 2022 - HackerNoon Contributor of the Year - Software Engineering

Nominated for 2022 - HackerNoon Contributor of the Year - Clean Code

Nominated for 2022 - HackerNoon Contributor of the Year - Debugging

Nominated for 2022 - HackerNoon Contributor of the Year - Backend

Nominated for 2022 - HackerNoon Contributor of the Year - Java

該音頻是用故事的原始語言製作的！

太長; 讀書

学习如何在 Java 中使用不可变和可靠的对象

学习如何在 Java 中使用不可变和可靠的对象

About Author

註釋

標籤

这篇文章刊登在

Related Stories

从论坛到信息流：社交媒体算法如何塑造数字互动

比特币 UTXO 模型，为独特的生态系统提供动力

Floki 的 Valhalla 成为印度环斯里兰卡赛事联合赞助商

Claude Sonnet 3.5 系统提示泄漏：法医分析

从论坛到信息流：社交媒体算法如何塑造数字互动

比特币 UTXO 模型，为独特的生态系统提供动力

Floki 的 Valhalla 成为印度环斯里兰卡赛事联合赞助商

Claude Sonnet 3.5 系统提示泄漏：法医分析

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps