通过不直接处理它的中间方法传递相同的变量

时间:2016-11-03 15:19:40

标签: algorithm performance language-agnostic readability

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

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的中间件。是否有更好的性能,设计和/或可读性实践?

2 个答案:

答案 0 :(得分:2)

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

  1. 你肯定想避免这样的代码 - 因为你很难将参数列表减少到绝对最小值;目标是
  2. 如果您发现您的班级应该提供各种方法,所有方法都需要“相同”参数;而这使得该参数成为您班级中的一个领域。
  3. 在非oo语言中,我认为您必须务实地在更多函数和参数列表长度之间取得平衡。在您的示例中,

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

    避免使用method1 ...将var3传递给第一个方法。而你仍处于“单一抽象”原则的规则之内。

答案 1 :(得分:1)

这并不罕见,也不一定是不好的做法。它可以影响您提到的所有三个指标:

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

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

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

  4. 通常,最好将参数列表最小化(出于所有这些原因)并使数据“更接近”需要它的代码。如果你做这些事情,这种情况不应该弹出太多,当它出现时,它不太可能是由于糟糕的设计。