java - Kotlin内联类，在后台实现接口(interface)

在Kotlin vesion 1.3.0中，内联类可供开发人员使用。

promise “普通”内联类在运行时不是真正的对象，而仅在编译时用于类型检查。

例如

inline class MyWrapper(val someString: String)

fun consumeMyWrapper(myWrapper: MyWrapper)

应该编译为以下等效的java:

public void consumeMyWrapper~blabla(String myWrapper)

但这也可以:

interface A {

    fun doJob(b: B)
}

inline class C(val self: D): A {

    override fun doJob(b: B)
}

所以我想知道它到底如何编译。我不知道bytecode，所以我要求一般原则。

但是，如果在运行时不存在应实现某些接口(interface)的对象，则其他人必须实现该接口(interface)。它会成为内联类的接收者吗？如果接收者碰巧是不可修改的类型(例如，来自其他已经编译的库)，将会发生什么？

我有这些担忧的原因与我偶然发现的一个问题有关。我需要一种更清洁的方法来在大型项目中与Fragment进行通信。旧的方式只是说Activity，它不是“很干净”。所以我定义了这个接口(interface):

interface ActivityDelegate {

    val view: View

    val routing: Routing

    interface View {
       // All common view related stuff
    }

    interface Routing {
       // BottomNavigtion related stuff
    }
}

并实现如下:

class MainActivity : Activity(), ActivityDelegate {

    override val view by lazy { MainActivityView(this) }

    override val routing by lazy { MainActivityRouting(this) }
}

internal inline class MainActivityView(val self: MainActivity): ActivityDelegate.View

internal inline class MainActivityRouting(val self: MainActivity): ActivityDelegate.Routing

我将这种方法与内联类一起使用，以从MainActivity和委托(delegate)职责中移出一些逻辑。

因此，我担心的是，是否适合在此使用内联类。在此特定方案中使用时，会有所不同吗？

最佳答案

不完全的:



特别是，内联类本身实现了接口(interface)。并且当将内联类与接口(interface)一起用作静态类型时，正是将其装箱的情况之一(如以上链接的示例所示)。在您的情况下，我相信它会自动装箱，而inline不会给您带来任何好处。