最近,在我的公司审查了编写重型课程的不同方法后,开始了一场辩论。
一个包含组件特定逻辑的大型 Java 类(没有标准的 OOP 原则有意义)必须用 Kotlin 重写。提供的解决方案是将逻辑划分为类别,并将类别划分为单独的文件,并具有主类的内部扩展功能。
例子:
Main.kt
class BigClass {
// internal fields exposed to the extension functions in different files
// Some main logic here
}
BusinessLogic.kt
internal fun BigClass.handleBussinessCase() {
// Complex business logic handled here accessing the exposed internal fields from BigClass
}
Run Code Online (Sandbox Code Playgroud)
您对此有何看法?我还没有看到它在任何地方使用,也许有充分的理由,但千行类的替代方案似乎更糟糕。
您必须考虑到扩展函数只不过是一个带有隐式第一个参数的函数,该参数由 引用this
。
所以在你的情况下你会有类似的东西:
internal fun handleBussinessCase(ref: BigClass)
Run Code Online (Sandbox Code Playgroud)
翻译成Java如下:
static void handleBussinessCase(BigClass ref)
Run Code Online (Sandbox Code Playgroud)
但这可以假设为委托模式,它也可以在Kotlin中封装得更清晰。
由于属性无论如何都必须是内部的,因此您可以将它们作为 a 注入data class
到较小的用例中。如果您围绕这些定义一个接口(这将使属性公开),您可以使用它创建一个委托模式,并且仍然this
在您的实现中引用每个属性。
归档时间: |
|
查看次数: |
2182 次 |
最近记录: |