【问题标题】:Passing the same variable through intermediate methods which don't directly process it通过不直接处理它的中间方法传递相同的变量
【发布时间】:2016-11-03 15:19:40
【问题描述】:

我经常发现自己将一个变量传递给一个方法,该方法不直接使用,而是传递给另一个方法进行进一步处理。我也不知道这种做法有没有名字。我可以用示例代码更好地解释它:

static void main() {
    int a = method1(var1, var2, var3)
}

int method1(int var1, int var2, int var3) {
    var4 = some_function_of(var1, var2)
    return method2(var3, var4)
}

int method2(int var 3, int var4) {
    return some_other_function_of(var3, var4)
}

这种情况可以扩展为相同的变量(var3)通过更长的方法链。我认为这可能是一种不好的做法,因为在我的示例中 method1 是某种不操纵 var3 的中间体。在性能、设计和/或可读性方面是否有更好的做法?

【问题讨论】:

  • 这个 AFAIK 没有名字,因为它只是正常的做法。它不会导致任何问题,除非您可能没有大量参数,在这种情况下,是时候开始将它们捆绑到类或结构中了。
  • @PaulR 如果方法链很长,那么我们不应该将变量声明为全局变量吗?这会是一件好事吗?
  • @Shubham:全局变量通常是个坏主意——它们破坏了模块化和解耦,可能不是线程安全的,并且会阻止某些编译器优化。该规则的例外往往是系统范围的全局变量,例如调试级别,但一般尽量避免使用全局变量。

标签: algorithm performance language-agnostic readability


【解决方案1】:

至少对于面向对象语言来说,答案是:

  1. 您绝对希望避免此类代码 - 因为您努力将参数列表减少到绝对最小值;目标是
  2. 如果你发现你的类应该提供各种需要“相同”参数的方法;比这使该参数成为您班级中的字段的候选者。

在非 oo 语言中,我认为您必须在具有 更多 函数和 参数列表长度 之间进行务实的平衡。在你的例子中,

static void main() {
  int var4 = some_function_of(var1, var2)
  int a = method2(var3, var4)
}

避免 method1 ... 可以节省您将 var3 传递给您的第一个方法。而且你仍然在“单层抽象”原则的规则之内。

【讨论】:

  • 谢谢,我同意平衡模块化和参数长度列表的想法。我想这是一个设计选择。对于一直困扰我的这个问题没有一个明显和理想的答案,我有点松了一口气
  • 如果 IT / 计算机科学领域的所有问题中的一小部分都能得到明显和理想的答案……那么我们就不会得到那么多报酬,对吧。当然:不要忘记接受你喜欢的答案......我怀疑你会听到很多关于你的问题的其他信息(因为你的标签并没有引起太多关注我认为)
【解决方案2】:

这一点也不罕见,也不一定是坏习惯。它可能会影响您提到的所有三个指标:

  1. 性能:向函数调用添加另一个参数可能会导致性能下降,但并非总是如此。它取决于语言、编译器/解释器和平台。例如,针对 C++ 的优化编译器将尽量避免复制变量,即使它可以通过值传递(有时它会完全消除函数调用)。但是如果不能很好地遵循路径,通过多个函数传递一个值可能会弄乱编译器的优化。不过,我预计这对性能造成的影响很小。

  2. 设计:根据您的语言范式(面向对象、函数式等),这可能表明您的设计可以改进,也许可以通过将数据封装在结构或类中以便只有一个参数是传递(一个类实例指针)并且每个函数只访问它需要的类成员。

  3. 可读性:这不应该使单个函数更难阅读,因为它们不应该关心参数的来源,而且很明显参数正在传递给另一个函数。但是,这可能会使整个程序的理解变得更加困难,因为如果值在被触及之前通过一长串调用传递,则很难跟踪值的来源。

一般来说,最好尽量减少参数列表(出于所有这些原因)并使数据“更接近”需要它的代码。如果你做了这些事情,这种情况就不应该出现太多,而且当它出现时,它不太可能是由于糟糕的设计造成的。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2020-05-08
    • 2016-11-03
    • 1970-01-01
    • 2011-02-18
    相关资源
    最近更新 更多