从Java转Kotlin：实例化调用其他类方法是否可行？

核心结论 #

这种实例化调用的方式技术上完全可行，但从性能、代码风格和维护性角度看，对于无状态的Helper类来说并不是最优选择；而对于有状态的业务类，实例化调用是合理的常规操作。

1. 性能层面的影响 #

像你代码里的ConversionHelper这类无状态类（没有成员变量，方法都是纯函数），每次实例化的开销非常小——Kotlin创建空对象的成本极低，JVM的逃逸分析甚至可能把这类对象分配在栈上，直接消除对象创建的开销。

但如果在高频调用场景（比如循环中反复创建实例），累积的冗余实例可能会带来微小的性能损耗；不过日常业务开发中，这种损耗基本可以忽略不计。真正的问题在于没必要的冗余操作——明明可以复用一个实例，却每次都新建，显得不够简洁。

2. 代码风格与维护风险 #

每次实例化无状态Helper类会让其他开发者产生困惑：这个类是否持有状态？为什么不复用实例？如果后续有人给ConversionHelper添加了成员变量（比如默认温度单位配置），每次实例化会导致状态不共享，很容易引入隐蔽的bug。

更优的替代方案 #

无状态工具类：优先用object声明单例

你的ConversionHelper是典型的无状态工具类，用Kotlin的object是最贴合语言习惯的写法，既保证全局唯一实例，调用也更简洁：

object ConversionHelper {
    fun convertTemperature(value: Int) {
        //code...
    }

    fun convertPressure(value: Int) {
        //code...
    }
}

调用时直接写ConversionHelper.convertTemperature(tempValue)即可，无需每次实例化。

非工具类的其他场景：实例化调用是合理的

如果是有状态的业务类（比如持有依赖对象、配置信息），实例化调用是面向对象开发的常规操作，完全没问题。例如一个需要依赖Api实例的服务类：

class UserService(private val api: UserApi) {
    fun getUserInfo(userId: String): User {
        return api.fetchUser(userId)
    }
}

这种类必须通过实例化传入依赖，调用方式是合理的。

混合场景：用companion object

如果类本身需要被实例化（有非静态业务方法），同时需要一些不依赖实例状态的工具方法，这时用companion object更合适：

class OrderService(private val db: OrderDatabase) {
    // 实例方法，依赖数据库
    fun saveOrder(order: Order) {
        db.insert(order)
    }

    // 静态工具方法，不依赖实例状态
    companion object {
        fun calculateTotalPrice(items: List<OrderItem>): Double {
            return items.sumOf { it.price * it.quantity }
        }
    }
}

总结 #

• 无状态工具类：用object替代每次实例化，代码更简洁，避免冗余
• 有状态业务类：正常实例化调用，符合面向对象设计
• 混合场景：用companion object区分实例方法和静态工具方法

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