Java 到 Kotlin

第18章 向密封班级开放

本作品已使用人工智能进行翻译。欢迎您提供反馈和意见：[e-mail]

我们的系统由类型和操作、名词和动词组成。 在 Java 中，名词表现为类和接口，动词表现为方法；但 Kotlin 增加了密封的类层次结构和独立函数。 它们带来了什么？

变化 是设计软件的一个永恒挑战。人们使用我们的软件越多，他们就会想出更多希望软件做的事情。 为了支持新的用例，我们需要添加与现有数据类型协同工作的新函数，以及与现有函数协同工作的新数据类型。 如果我们的设计能很好地与软件必须发展的方式保持一致，我们就可以通过添加新代码和对现有代码进行少量局部修改来增加新功能。 如果不能很好地保持一致，我们就必须在添加新数据类型时更改许多函数，或者在需要添加函数时更改许多数据类型。

在我们领域模型的核心实体中，我们最能感受到数据类型和功能之间的这种紧张关系。 例如，旅行者的行程是我们 Travelator 应用程序的核心实体。 该应用程序的许多功能都显示了行程的视图、更改了行程的内容或计算了行程的信息。 因此，用户提出的许多功能要求都会影响到我们的Itinerary 类型，这并不奇怪。 我们的旅行者希望在他们的行程中包含更多内容：不仅仅是第 10 章中提到的行程和住宿，现在还包括餐厅预订和沿途景点。 他们还希望在行程中做更多事情。 在第 14 章中，我们介绍了如何估算行程成本，但我们的客户还希望通过成本、时间或舒适度对行程进行比较，在地图上查看行程，将行程导入日历，与朋友分享行程......他们的想象力无穷无尽。

上次我们在第 14 章中学习Itinerary 类时，我们将行程作为一个数据类来建模，其中一个属性表示路线，另一个属性表示沿途所需的住宿：

data class Itinerary(
    val id: Id<Itinerary>,
    val route: Route,
    val accommodations: List<Accommodation> = emptyList()
) {
    ...
}

例 18.1 [accumulator.17:src/main/java/travelator/itinerary/Itinerary.kt] (diff)

从那时起，我们在应用程序中添加了更多的功能，因此行程中的项目类型也越来越多。 我们发现，将每种类型的行程项目保存在一个单独的集合中越来越麻烦，因为我们有太多的代码需要合并这些集合，或对不同的集合应用相同的过滤器和转换。因此，我们决定Itinerary 将维护ItineraryItem 的单一集合，而不是将每种类型的项目保存在一个单独的集合中：

data class Itinerary(
    val id: Id<Itinerary>,
    val items: List<ItineraryItem>
) : Iterable<ItineraryItem> by items

例 18.2 [open-to-sealed.0:src/main/java/travelator/itinerary/Itinerary.kt] (diff)

ItineraryItem 是一个接口，由我们之前看到的具体项目类型 和 以及新类型 和 实现：Journey Accommodation RestaurantBooking Attraction

interface ItineraryItem {
    val id: Id<ItineraryItem>
    val description