Kotlin - 嵌套函数与具有 1 个调用站点的私有函数



每当我有一个函数变得足够大以保证分解为较小的函数时,我总是选择将较小的函数创建为较大函数范围的嵌套函数,如下所示:

class Foo {
fun bar() : Int {
fun a() : Int {
// Do a load of stuff
return 1
}
fun b() : Int {
// Do a load of stuff
return 1
}
return a() + b()
}
}

我这样做是因为它提供了这些函数的封装,这些函数到目前为止只有一个调用站点;封闭范围的函数。

但是,我在工作中经常被要求将这些函数重构为封闭类的私有函数,如下所示:

class Foo {
fun bar() : Int {
return a() + b()
}
private fun a() : Int {
// Do a load of stuff
return 1
}
private fun b() : Int {
// Do a load of stuff
return 1
}
}

我反对这一点的论点是,这些函数只有 1 个调用站点,并且通过将它们提升到类级别的私有函数,我正在用仅在一个地方调用的方法混淆类。

还可以提出一个额外的小论点,如果我将它们作为类的私有函数,那么稍后有人可以进来并开始在这些私有函数和调用它们的函数之间插入方法,这样调用站点和函数本身之间可能有 100 行代码,导致需要心理体操来理解调用函数(因为你现在需要滚动调用函数关闭查看私人功能的屏幕(。

我总是遵守并将它们移动到类的私有函数,因为我的论点不追求审稿人。

我的论点是否有效,或者是否有正当理由(性能、代码可读性(使我的论点无效?

我发现将嵌套函数转换为包含该函数的类中的私有函数非常令人困惑,因为唯一的目的只是提高主函数的可读性。私有子句只能防止在类外部无意中使用,但它会阻碍类源代码的可读性。

在效率方面,没有问题,恰恰相反,但它无关紧要。在编译器时代,在类中搜索有效函数更加简化,因为嵌套函数甚至不是数据字典的一部分。

在效率方面,当允许嵌套函数查看父函数的部分上下文时,开销很小,该上下文位于代码的前面部分。由于使用只是作为实现更好可读性的一种手段,我认为这没有问题。

作为一个私有函数,编译器可以在类中的任何位置访问该函数,我认为这是一个封装缺陷,因为这不是本地和 嵌套函数。

最新更新