以不变且透明的方式对数据进行建模是面向数据编程的四大原则之一。我们将探讨为何不变性和透明性在数据建模时如此重要,以及如何使用 Java 的功能(尤其是记录(Record))来实现这一点。
1.不变性和透明度
软件错误的一个常见来源是对象被不同子系统频繁修改。这种情况屡见不鲜,即代码基线一端的代码更改了实例,而另一端的代码却没有注意到这一点,尽管它需要对此作出反应。
一个特别简单而明显的例子是将对象存储在 HashSet 中,然后更改在哈希码计算中使用的值。 HashSet 没有注意到这种变化,无法在新的哈希码下重新读取该对象,结果,它突然无法被发现。
在此示例中,两个子系统(HashSet 和修改对象的代码)可以访问同一个对象,但修改它的要求不同,并且无法进行通信 - 开发人员必须了解它们。 在这里,这种情况经常发生,并且大多数 Java 开发人员都知道从可变字段计算哈希码是有问题的,但这只是这种情况,因为两个受影响的系统之一是一个众所周知的系统,具有简单的契约(“不要 去做”)——在更复杂和自建的系统中,这更难以跟踪。
保证正确性的最简单方法是不变性:如果没有什么可以改变,这样的错误就不会发生。 如果子系统仅与不可变数据进行通信,那么这种常见的错误源就完全消失了。
但如果数据无法更改,则必须在处理数据的系统中进行必要的状态更改。 正如可变对象可以在更改之前考虑其整个状态一样,这些系统现在必须考虑已处理对象的整个状态,并且为此对象必须是 透明的。 如果一个对象的内部状态可以通过 API 访问和构造,那么该对象就是透明的,即:
- 每个字段必须有一个返回相同 (==) 或至少相等 (equals) 值的访问方法。
- 必须有一个构造函数接受所有字段的值,并且如果它们在有效范围内,则直接保存它们或至少保存为副本。
总而言之,这意味着给定一个现有实例,您可以通过查询所有字段并调用适当的构造函数来创建一个新实例,该实例除了其标识 (==) 之外与第一个实例没有区别。
2.记录(Records)
因此,我们希望与不可变数据的透明载体合作。 幸运的是,记录就是这样设计的! 在 Java 16 中最终确定,记录通过声明所谓的组件来将数据描述为其类型定义的一部分,每个组件都指定一个类型和名称。 例如,如果我们想要对一本书的标题、ISBN 和作者的数据进行建模,那么自然的方法如下:
record Book(String title, ISBN isbn, List<Author> authors) { }
要充当透明数据载体,必须满足许多要求:
- 每个组件都必须有一个字段来存储其值。
- 这些字段必须是最终的(“不可变数据”)。
- 必须有一个规范的构造函数来准确地接受和分配这些值,以及返回它们的访问器方法(构造和访问中的透明性)。
- 类型必须是最终的(否则记录的组件将无法完全描述数据)。
- equals 和 hashCode 方法基于此数据,而不是基于记录实例的身份(“数据载体”)。
Java 并没有让我们来满足这些要求,而是负责并生成所有这些东西。 (这就是我们在使用记录时享受的样板文件的减少,但重要的是要理解这不是它们的目的,而是它们实际目的的一个受欢迎的副作用:成为不可变数据的透明载体。)
这就是为什么您可以在一行中定义简单的记录,尽管我们很快就会看到,在实践中,调整是非常常见的。 这些都是完全可能的:
- 规范的构造函数、访问器方法、equals 和 hashCode 可以被重写并因此被定制。
- 可以添加更多构造函数和任意方法(但不能添加字段或“私有组件”,因为这与透明度相矛盾)。
- 记录可以实现接口。
在我们继续之前,我想指出记录简化了面向数据的编程,但它既不是必需的也不是强制的。 例如,如果它们的局限性之一阻止它们用于特定类型,则只要仍然遵守 DOP 原则,您就可以将其设计为普通类。 在此原则的背景下,这意味着将类设计为不可变且透明的。
3.深度不变性
记录字段是最终的,但这并不神奇地适用于它们引用的内容:
record Book(String title, ISBN isbn, List<Author> authors) { }var threeBP = new Book("深入理解java虚拟机",new ISBN("9787111349662"),new ArrayList<>());
threeBP.authors().add(new Author("周志明"));
在此示例中,作者列表可以在构建后更改! 为了防止这种情况,如果可能的话,记录应该在其构造函数中创建可变数据结构的不可变副本。 List、Set 和 Map 的 copyOf 方法适用于 Java 集合:
record Book(String title, ISBN isbn, List<Author> authors) {Book {authors = List.copyOf(authors);}}
这里我使用了一个紧凑的构造函数,它不需要显式的参数列表或字段赋值。 紧凑构造函数的参数正是记录的组成部分,执行代码块后,值会自动分配给字段。 因此构造函数必须只包含绝对必要的内容 - 这里通过调用 List.copyOf 来复制作者列表。 由于结果列表是不可变的,因此如上所述调用authors().add(…) 会导致异常。
对于其他数据结构,尤其是您自己的数据结构,这可能会更加复杂。 如果无法创建不可变副本,您可以通过在构造函数中创建一个副本,然后在覆盖的访问方法中创建另一个副本,来确保没有人可以引用记录的内部状态:
record Book(String title, ISBN isbn, List<Author> authors) {Book {authors = List.copyOf(authors);isbn = new ISBN(isbn);}@Overridepublic ISBN isbn() {return new ISBN(isbn);}
}
尽管这可能是意外的并且还会导致错误,但它通常比更改记录状态本身的问题要少。
如果没有技术解决方案,也许沟通性的解决方案会有所帮助:团队可以同意将从记录中获得的所有内容视为不可变,并且不调用更改数据结构的方法。
4.总结
减少代码库中错误的可靠方法是限制潜在麻烦操作的范围,而最重要的是在多个子系统之间共享的状态突变。 面向数据的编程提出子系统通过不可变且透明地建模的数据进行通信。 Java 使记录的这一点变得特别容易,尽管当记录引用可变数据结构时需要小心一些。