java修改数据历史记录_记录更新（Java数据类）

java修改数据历史记录

最近几个月，有一些与“ Java数据类”（又称为“记录”）有关的更新。正如我在“ JavaFX，Valhalla，数据类和Java的浮点更新 ”一文中简短提到的那样， Brian Goetz的“ Java数据类 ”“探讨了Java语言中数据类的可能方向。” 令人遗憾的是，尽管在OpenJDK邮件列表上对这一潜在的新Java功能进行了大量讨论，但该文档还指出：“这只是一个探索性文档，并不构成任何特定Java语言版本中任何特定功能的计划。”

3月中旬，Goetz在琥珀色专家的邮件列表中张贴了一条消息，标题为“ 记录-当前状态” 。他在该消息中指出了Java记录的意图：“我们一直以来的目标是将记录定义为一组更细粒度的功能的'纯宏'。其中一些是由样板驱动的；有些是由语义（将API元素的语义耦合到状态）驱动的。通常，记录将首先到达那里，然后普通的类将具有更通用的功能。”

“ 记录-当前状态 ”一文中提出了一些有趣的观点，但在这里我将重点介绍一些我发现特别有趣的观点。通常，在陈述的早期设计决策中可以看到，与创建Java相比，现在普遍流行的通用原则主导着与记录有关的思维。

在“可变性和可访问性”部分中，Goetz建议Java记录提供final字段，这些字段是“默认情况下为打包（ protected抽象记录protected ）的软件包”，但允许开发人员“显式选择退出（非最终）”，因为并允许“明确扩展（公开）访问范围”。我喜欢的有Java结构的想法final默认领域，并具有明确选择，使他们非final ，而不是周围的其他方式，我们已经成为在Java中使用。

Goetz在“访问器”部分中写道，当前的想法是让这些访问器方法不使用JavaBeans的“ get”约定，而使用不带“ get”前缀的字段名称。他写道：“显而易见的选择是自动公开读取访问器。（这些将不会被命名为getXxx；无论人们已经考虑了多少，我们都不会将不明智的Javabean命名约定烧入该语言。）这些访问器的明显命名选择是fieldName（）。” 我喜欢遵循此简单命名约定（在编写builder时倾向于使用）自动生成的读取访问器的想法。我还赞赏强调的保证，即没有阴谋或努力将“不明智的JavaBean命名约定烧入该语言中”。

Goetz的“核心方法”部分讨论了常见方法，例如equals(Object) ， hashCode() ， toString()等。 Goetz写道：“记录将获得equals，hashCode和toString”，并且“将equals / hashCode最终定为一个很好的论据。” 他补充说，虽然无需将toString()为final方法，但可以将自动生成的读取访问器方法设置为final 。

Stephen Colebourne在有关Java中的记录/数据类的邮件列表讨论中贡献了多个帖子。这些包括他在Amber上发表的见解（该项目包括这项工作以及其他工作，例如LVTI和原始字符串文字），以及对先前提到的原始“ Records-current status ”消息的回应。

关于Java记录的其他相对较新的邮件列表消息包括Goetz的“ 记录：构造和验证” ，由Remi Forax开始的“ 记录和注释值 ”讨论，以及由Gunnar Morling发起的名为“ Records- 将它们用作JPA实体”的主题。并使用Bean验证对其进行验证。”

尽管Records / Data Classs尚未与任何特定的Java版本相关联，但令人激动的是，思考它们可能带来的使更好，更安全和可读性更好的Java代码的可能性。