具有空组件的Java记录

本文介绍了具有空组件的Java记录的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述

我真的很喜欢至少在Java 14中添加记录作为预览功能，因为它有助于减少我对简单，不可变的数据持有者"使用lombok的需求.但是我在实现可为空的组件方面遇到了问题.我试图避免在我的代码库中返回 null 来指示可能不存在值.因此，我目前经常在龙目岛上使用以下模式.

I really like the addition of records in Java 14, at least as a preview feature, as it helps to reduce my need to use lombok for simple, immutable "data holders". But I'm having an issue with the implementation of nullable components. I'm trying to avoid returning null in my codebase to indicate that a value might not be present. Therefore I currently often use something like the following pattern with lombok.

@Value public class MyClass { String id; @Nullable String value; Optional<String> getValue() { // overwrite the generated getter return Optional.ofNullable(this.value); } }

当我现在对记录尝试相同的模式时，不允许这样做，指出不正确的组件访问器返回类型.

When I try the same pattern now with records, this is not allowed stating incorrect component accessor return type.

record MyRecord (String id, @Nullable String value){ Optional<String> value(){ return Optional.ofNullable(this.value); } }

由于我认为现在首选使用 Optional 作为返回类型，所以我真的很想知道为什么要设置此限制.我对用法的理解有误吗?如何在不添加其他访问者的情况下实现相同的目的，而该访问者的另一个签名不会隐藏默认访问者呢?在这种情况下应该完全不使用 Optional 吗?

Since I thought the usage of Optionals as return types is now preferred, I'm really wondering why this restriction is in place. Is my understanding of the usage wrong? How can I achieve the same, without adding another accessor with another signature which does not hide the default one? Should Optional not be used in this case at all?

推荐答案

记录包含主要定义其状态的属性.访问器，构造函数等的派生完全基于记录的状态.

A record comprises attributes that primarily define its state. The derivation of the accessors, constructors, etc is completely based on this state of the records.

现在在您的示例中，属性 value 的状态为 null ，因此使用默认实现的访问最终将提供真实状态.为了提供对此属性的自定义访问，您需要寻找一个覆盖实际状态并进一步提供 Optional 返回类型的重写API.

Now in your example, the state of the attribute value is null, hence the access using the default implementation ends up providing the true state. To provide customized access to this attribute you are instead looking for an overridden API that wraps the actual state and further provides an Optional return type.

当然，您提到的一种解决方法是在记录定义本身中包含一个自定义实现

Ofcourse as you mentioned one of the ways to deal with it would be to have a custom implementation included in the record definition itself

record MyClass(String id, String value) { Optional<String> getValue() { return Optional.ofNullable(value()); } }

或者，您可以在单独的类中将读写API与数据载体分离，然后将记录实例传递给它们以进行自定义访问.

Alternatively, you could decouple the read and write APIs from the data carrier in a separate class and pass on the record instance to them for custom accesses.

我发现的 JEP 384:记录中最相关的报价是(格式化我的):

The most relevant quote from JEP 384: Records that I found would be(formatting mine):

一条记录声明其状态-变量组-并提交匹配该状态的API.这意味着记录放弃了班级通常享有的自由-使人与人解耦的能力类的API的内部表示形式-但作为回报，变得更加简洁.

A record declares its state -- the group of variables -- and commits to an API that matches that state. This means that records give up a freedom that classes usually enjoy -- the ability to decouple a class's API from its internal representation -- but in return, records become significantly more concise.