为什么这个 Kotlin 类是抽象类？答案

【问题标题】：Why is this Kotlin-class an abstract class?为什么这个 Kotlin 类是抽象类？
【发布时间】：2023-01-28 12:34:10
【问题描述】：

我得到了有人写的这段代码：

abstract class ListItem {
    companion object {
        private var id = 0
        fun getUUID() = id++
    }
}

fun getItem(uuid: Int): ListItem? {
    for (dessert in Dessert.getAllDesserts())
        if (dessert.id == uuid)
            return dessert
    for (fruit in Fruit.getAllFruits())
        if (fruit.id == uuid)
            return fruit
    return null
}

子类示例：

data class Fruit(
    val id: Int,
    val resId: Int,
    val name: String,
    val origin: String,
    val desc: String
): ListItem() {
    companion object {
        private val fruits = listOf(
            Fruit(getUUID(), R.drawable.f1_durian, "Durian", "Indonesia", "Often dubbed the king of fruit, durian is an unusual tropical fruit that grows throughout Southeast Asia. A large spiky outer shell reveals a creamy, almost custard-like flesh, which, besides boasting a mildly sweet flavor, is notorious for being incredibly rank-smelling."),

我不明白为什么 ListItem 是一个抽象类。没有未实现的方法。

使 ListItem 成为抽象类的动机是什么？

有人有想法吗？

【问题讨论】：

更大的背景是什么？ ListItem 是如何子类化的？这些子类是如何使用的？
目标是禁止直接创建此类的对象。
@Slaw 我添加了一个子类示例。
@mrmcwolf 谢谢。但这种方法的动机是什么？分别禁止直接创建的好处是什么？
假设您有一家水果店。你可以把水果放在看台上，对吧？除了你不能放水果，因为它没有任何意义，它是一种抽象。你必须放一些具体的东西，苹果、香蕉、梨……这是这个约束的软件实现。

标签： kotlin oop

【解决方案1】：

就像mr mcwolf 给出的伟大示例一样，这里的“问题”是一个概念性问题：虽然您可以允许实例化 ListItem，但它的目的是什么？如果我们谈论食品，它没有“物理”意义。

但是，重要的是要注意 interface 将是更好的方法，因为在您提供的示例中使用继承没有实际好处，甚至可能会产生误导。

如果在这种情况下，ListItem 变成了一个“标记”interface，它就达到了不能直接实例化的目的，并有助于泛型类型化（例如，如果稍后使用），同时不会破坏其他一些所需的行为（例如，将Fruit 和Dessert 置于Food 层次结构下）。

【讨论】：