如何构建Kotlin泛型接口继承链？求更优雅设计方案

当前核心问题是：IOTestSet想要复用ITestSet和OTestSet的方法与属性，但两者分别继承了不同泛型参数的TestAdder接口，导致多重继承时需处理同名方法的重载逻辑。以下是几种可行的解决思路：

方案一：显式指定重载方法的父类实现 #

Kotlin支持接口方法重载，ITestSet和OTestSet中的add_f是不同参数类型的重载（分别接收ITest<I>和OTest<O>），只需显式指定每个重载方法对应的父接口实现，就能复用两个集合接口的所有默认方法与属性：

interface IOTestSet<I, O> : ITestSet<I>, OTestSet<O>, TestAdder<IOTest<I, O>> {
    fun io_f1(p: I): O

    // 继承ITestSet中add_f的默认实现
    override fun add_f(p: ITest<I>) = super<ITestSet>.add_f(p)
    // 继承OTestSet中add_f的默认实现
    override fun add_f(p: OTest<O>) = super<OTestSet>.add_f(p)
    // 保留自身TestAdder<IOTest<I,O>>的默认实现
    override fun add_f(p: IOTest<I, O>) = super<TestAdder>.add_f(p)
}

这种方式完全消除代码冗余，同时清晰处理了多重继承下的方法重载逻辑，是最直接的解决方案。

方案二：拆分TestAdder为语义化子接口 #

如果觉得泛型参数的重载不够直观，可以将TestAdder拆分为更具语义的子接口，避免泛型混淆：

// 针对不同组件接口的专用Adder接口
interface ITestAdder : TestAdder<ITest<*>>
interface OTestAdder : TestAdder<OTest<*>>
interface IOTestAdder : TestAdder<IOTest<*, *>>

// 修改集合接口继承对应的专用Adder
interface ITestSet<I> : ITestAdder {
    val i_v: I
    fun i_f1(p: I) {}
    fun i_f2(p: I) {}
    fun i_f3(p: I) {}
}

interface OTestSet<O> : OTestAdder {
    val o_v: O
    fun o_f1(p: O) {}
    fun o_f2(p: O) {}
    fun o_f3(p: O) {}
}

// 此时IOTestSet继承三个专用接口，语义更清晰
interface IOTestSet<I, O> : ITestSet<I>, OTestSet<O>, IOTestAdder {
    fun io_f1(p: I): O
}

这种方式通过语义化子接口降低了泛型使用的复杂度，同样实现了代码复用，后续扩展时更易维护。

方案三：委托模式替代多重继承 #

如果接口继承约束较多，可用委托模式复用ITestSet和OTestSet的功能，灵活性更强：

// 定义IOTestSet的基础接口
interface IOTestSet<I, O> : TestAdder<IOTest<I, O>> {
    val i_v: I
    val o_v: O
    fun i_f1(p: I)
    fun i_f2(p: I)
    fun i_f3(p: I)
    fun o_f1(p: O)
    fun o_f2(p: O)
    fun o_f3(p: O)
    fun io_f1(p: I): O
}

// 通过委托实现IOTestSet
class IOTestSetImpl<I, O>(
    private val iTestDelegate: ITestSet<I>,
    private val oTestDelegate: OTestSet<O>
) : IOTestSet<I, O> {
    override val i_v: I get() = iTestDelegate.i_v
    override val o_v: O get() = oTestDelegate.o_v

    override fun i_f1(p: I) = iTestDelegate.i_f1(p)
    override fun i_f2(p: I) = iTestDelegate.i_f2(p)
    override fun i_f3(p: I) = iTestDelegate.i_f3(p)

    override fun o_f1(p: O) = oTestDelegate.o_f1(p)
    override fun o_f2(p: O) = oTestDelegate.o_f2(p)
    override fun o_f3(p: O) = oTestDelegate.o_f3(p)

    override fun io_f1(p: I): O {
        // 自定义实现逻辑
        TODO()
    }

    override fun add_f(p: IOTest<I, O>) {}

    // 暴露委托的add_f方法
    fun addITest(p: ITest<I>) = iTestDelegate.add_f(p)
    fun addOTest(p: OTest<O>) = oTestDelegate.add_f(p)
}

这种方式虽需编写委托代码，但避免了接口继承的冲突问题，适合后续功能扩展复杂的场景。

内容的提问来源于stack exchange，提问作者t.ry