scala - 在 Scala 应用程序的设计中如何实际实现不变性？

Question

作为 scala 的新手和当前的 java 开发人员，scala 旨在鼓励在类设计中使用不变性。

这实际上如何转化为类的设计？我唯一想到的是案例类。是否强烈鼓励使用案例类来定义数据？例子？在 Scala 类设计中还有什么鼓励不变性的？

作为 Java 开发人员，定义数据的类是可变的。等效的 Scala 类应该定义为案例类吗？

Answer 1

好吧，案例类当然有帮助，但最大的贡献者可能是集合库。默认集合是不可变的，并且这些方法旨在通过生成新集合而不是变异来操作集合。由于不可变集合是持久化的，因此不需要复制整个集合，而这是 Java 中经常要做的事情。

除此之外，for-comprehensions 是 monadic comprehensions，它有助于执行不可变任务，还有尾递归优化，这在不可变算法中非常重要，并且在许多库中普遍关注不变性，例如解析器组合器和 xml。

最后，请注意，您必须要求提供 var获得一些可变性。参数是不可变的，并且 val就像 var 一样短.将此与 Java 对比，其中参数是可变的，您需要添加 final关键字以获得不变性。在 Scala 中保持不可变同样容易或更容易，而在 Java 中保持可变更容易。

附录

Persistent data structures是在其修改版本之间共享部分的数据结构。这可能有点难以理解，所以让我们考虑 Scala 的 List ，这是非常基本且易于理解的。

一个 Scala List由两个类组成，称为 cons 和 Nil .前者其实写的是::在 Scala 中，但我会用传统名称来指代它。
Nil是空列表。它不包含任何东西。依赖列表不为空的方法，如 head和 tail抛出异常，而其他人工作正常。

自然地， cons 必须代表一个非空列表。事实上， cons 正好有两个元素:一个值和一个列表。这些元素被称为头和尾。

所以一个包含三个元素的列表由三个 cons 组成，因为每个 cons 将只包含一个值，加上一个 Nil .它必须有一个 Nil因为 cons 必须指向一个列表。由于列表不是循环的，因此其中一个缺点必须指向缺点以外的内容。

此类列表的一个示例如下:

val list = 1 :: 2 :: 3 :: Nil

现在，Scala 的组件 List是不可变的。一个人不能改变 cons 的值和列表。不变性的一个好处是你永远不需要在传递之前或从其他方法接收之后复制集合:你知道列表不能改变。

现在，让我们考虑一下如果我修改该列表会发生什么。让我们考虑两个修改:删除第一个元素并添加一个新元素。

我们可以使用方法 tail 删除一个元素，其名字绝非巧合。所以，我们写:

val list2 = list.tail

和 list2将指向与 list 相同的列表的尾部指向。什么也没有创建:我们只是重用了 list 的一部分.所以，让我们在 list2 前面添加一个元素然后:

val list3 = 0 :: list2

我们在那里创建了一个新的缺点。这个新的 cons 的值(头)等于 0，它的尾指向 list2 .请注意， list和 list3指向同一个 list2 .这些元素由 list 共享和 list3 .

还有许多其他持久性数据结构。您正在操作的数据是不可变的，这一事实使得共享组件变得容易。

可以在 Chris Okasaki 所著的书中找到有关此主题的更多信息， Purely Functional Data Structures ，或在他免费提供 thesis同名。