如何为含reified泛型的库内联函数实现依赖注入？

背景与需求 #

有一个无法修改的第三方库方法，定义如下：

class Lib {
    inline fun <reified T> getSomething(): T {
        // ... 内部实现
    }
}

它通过reified泛型传递返回类型信息，但没有提供基于KClass<T>的替代接口。

我的需求是：

• 封装该库的功能，添加自定义逻辑
• 支持依赖注入，方便后续Mock测试
• 用密封接口Something限制泛型参数的范围：

sealed interface Something {
    // ...
}

// 期望的Wrapper接口
interface Wrapper {
    fun <T : Something> getSomething(): T
}

// 最初的尝试（无法运行）
class LibWrapper : Wrapper {
    private val library = Lib()

    override fun <T : Something> getSomething(): T {
        // ... 自定义逻辑
        val something = library.getSomething<T>() // 编译错误：非reified泛型无法传递给reified参数
        // ...
    }
}

这段代码无法运行，因为非reified的泛型参数仅在编译期存在，无法传递给库的reified方法。

已尝试的无效方案 #

1. 向上传播inline特性 #

尝试把inline和reified加到Wrapper接口中，但虚成员不能是inline函数，无法实现依赖注入（Mock类无法重写inline方法）：

internal interface Wrapper {
    inline fun <reified T : Something> getSomething(): T
}

internal class LibWrapper : Wrapper {
    private val library = Lib()

    override inline fun <reified T : Something> getSomething(): T {
        // ... 自定义逻辑
        val something = library.getSomething<T>()
        // ...
    }
}

2. 传递KClass参数 #

尝试用KClass<T>作为参数，但仍然无法将非reified的T传递给库方法：

interface Wrapper {
    fun <T : Something> getSomething(type: KClass<out T>): T
}

class LibWrapper : Wrapper {
    private val library = Lib()

    override fun <T : Something> getSomething(type: KClass<out T>): T {
        // ... 自定义逻辑
        val something = library.getSomething<T>() // 同样编译错误
        // ...
    }
}

可行思路分析 #

假设Something有两个实现类：

class A : Something {
    // ...
}

class B : Something {
    // ...
}

思路1：为每个实现类编写独立方法 #

为每个Something的实现类单独封装方法：

interface Wrapper {
    fun getA(): A
    fun getB(): B
}

class LibWrapper : Wrapper {
    private val library = Lib()

    override fun getA(): A {
        // ... 自定义逻辑
        return library.getSomething<A>()
        // ...
    }

    override fun getB(): B {
        // ... 自定义逻辑
        return library.getSomething<B>()
        // ...
    }
}

优点：类型安全，无强制类型转换，Mock实现简单。
缺点：当Something的实现类增多时，会产生大量重复代码，违背泛型的设计初衷。

思路2：手动映射KClass到具体调用 #

为Lib编写扩展方法，通过when语句将KClass映射到具体的reified调用：

@Suppress("UNCHECKED_CAST")
fun <T : Something> Lib.getSomething(type: KClass<out T>): T {
    return when(type) {
        A::class -> getSomething<A>() as T
        B::class -> getSomething<B>() as T
        else -> throw NotImplementedError("Unsupported type: $type")
    }
}

// 对应的Wrapper实现
interface Wrapper {
    fun <T : Something> getSomething(type: KClass<out T>): T
}

class LibWrapper : Wrapper {
    private val library = Lib()

    override fun <T : Something> getSomething(type: KClass<out T>): T {
        // ... 自定义逻辑
        return library.getSomething(type)
        // ...
    }
}

优点：代码量较少，Wrapper接口保持泛型风格，新增实现类仅需在when中添加分支。
缺点：需要手动维护类型映射，即使Something是密封接口，编译器也无法保证分支覆盖（仍需else分支），存在强制类型转换。

思路3：利用密封接口与反射优化（进阶方案） #

由于Something是密封接口，所有实现类在编译期都是已知的，可以结合反射自动生成映射逻辑，避免手动维护when分支：

@Suppress("UNCHECKED_CAST")
fun <T : Something> Lib.getSomething(type: KClass<out T>): T {
    // 获取密封接口的所有子类
    val subclasses = Something::class.sealedSubclasses
    check(type in subclasses) { "Unsupported type: $type" }
    
    // 通过反射调用reified方法
    val method = Lib::class.declaredFunctions.find { it.name == "getSomething" }
        ?: throw IllegalStateException("Method getSomething not found")
    
    // 由于reified方法是inline，实际编译后会直接生成对应类型的调用，这里需要确保类型匹配
    return method.call(this) as T
}

注意：这种方案依赖反射，可能存在性能损耗，且需要处理反射调用的异常。如果Lib的getSomething内部依赖reified的类型信息（比如T::class），反射调用可能无法正确传递类型，需要验证。

另外，由于你的Something实现类都是@Serializable数据类，也可以考虑结合序列化框架（如Kotlinx Serialization）的类型信息来辅助，但这需要库方法的逻辑与序列化兼容。

方案选择建议 #

• 如果Something的实现类数量少且长期稳定，优先选择思路1，它最简洁、类型安全，Mock也最方便。
• 如果Something的实现类可能频繁新增，选择思路2，它平衡了代码量和可维护性，虽然需要手动添加分支，但比重复编写方法高效。
• 如果追求极致的通用性且能接受反射的性能损耗，尝试思路3，但需要充分测试反射调用的正确性，确保与库方法的内部逻辑兼容。

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