Kotlin安卓游戏中枚举的使用是否合理？对比继承方案

问题背景 #

我正在用Kotlin开发一款安卓游戏，对当前枚举的使用方式存有疑问。我定义了ProductionInformation枚举存储各类生产项的初始参数，并在Production类中通过该枚举初始化实例属性，不清楚这种写法是否简洁规范，或是采用13个继承Production的子类实现会更优。

枚举定义代码 #

package com.example.makemoremeat.enumerations

import com.example.makemoremeat.R

enum class ProductionInformation(
    val initialNumber: Double,
    val initialCost: Double,
    val initialProduction: Double,
    val initialProductionTime: Double,
    val coefficientCostUp: Double,
    val imageProduction: Int
) {

    Chicken(1.0, 1.0, 0.1, 1.0, 1.13, R.drawable.production_work_in_progress),
    Beef(0.0, 7.0, 0.7, 2.0, 1.14, R.drawable.production_work_in_progress),
    Mutton(0.0, 49.0, 4.9, 4.0, 1.15, R.drawable.production_work_in_progress),
    Pork(0.0, 343.0, 34.3, 8.0, 1.16, R.drawable.production_work_in_progress),
    Rabbit(0.0, 2401.0, 240.1, 16.0, 1.17, R.drawable.production_work_in_progress),
    Horse(0.0, 16807.0, 1680.7, 32.0, 1.18, R.drawable.production_work_in_progress),
    Caribou(0.0, 117650.0, 11765.0, 64.0, 1.19, R.drawable.production_work_in_progress),
    Fish(0.0, 823540.0, 82354.0, 128.0, 1.20, R.drawable.production_work_in_progress),
    Dog(0.0, 5764800.0, 576480.0, 256.0, 1.21, R.drawable.production_work_in_progress),
    Elephant(0.0, 40354000.0, 4035400.0, 512.0, 1.22, R.drawable.production_work_in_progress),
    Bugs(0.0, 282480000.0, 28248000.0, 1024.0, 1.23, R.drawable.production_work_in_progress),
    Vegan(0.0, 1977300000.0, 197730000.0, 2048.01, 1.24, R.drawable.production_work_in_progress),
    Cultured(0.0, 13841000000.0, 1384100000.0, 4096.0, 1.25, R.drawable.production_work_in_progress)
}

Production类初始化代码 #

class Production (
    private val game: Game,
    private val productionInformation: ProductionInformation
) {

    val image = productionInformation.imageProduction
    var numberPossessed = productionInformation.initialNumber
    var actualCost =
        productionInformation.initialCost * productionInformation.coefficientCostUp.pow(
            numberPossessed - 1
        )
    var actualProduction = productionInformation.initialProduction
    var actualProductionTime = productionInformation.initialProductionTime
    // 其他代码省略
}

方案分析与结论 #

当前枚举方案的优势 #

• 简洁性：所有生产项的静态配置集中在一个枚举类中，无需创建13个独立子类，代码量少，维护成本低，新增生产项只需在枚举中添加一行即可。
• 规范性：枚举天然是单例，确保每种生产类型的配置唯一，避免重复实例化配置对象；同时通过构造函数强制约束所有生产项必须包含完整的初始参数，不会出现参数遗漏。
• 灵活性：Production类通过依赖注入枚举实例，实现逻辑与配置分离，后续修改生产参数只需调整枚举值，无需改动Production的核心逻辑。

子类方案的适用场景 #

如果后续每种生产项需要独特的行为逻辑（比如不同的成本计算规则、特殊的生产触发效果、差异化的升级逻辑），此时子类方案更合适——每个子类可以重写父类方法实现专属逻辑。但就目前代码来看，所有生产项的逻辑都是基于统一的初始参数计算，没有差异化行为，子类方案会造成代码冗余，反而增加维护负担。

结论 #

当前的枚举方案是更优的选择，完全符合简洁规范的要求。只有当未来每种生产项需要实现独特行为时，再考虑重构为子类继承的模式。

内容的提问来源于stack exchange，提问作者Amaroke