【问题标题】:Habit of making private methods static to increase functional programming [closed]将私有方法设为静态以增加函数式编程的习惯 [关闭]
【发布时间】:2014-09-13 05:24:39
【问题描述】:

我接触了函数式编程范式(haskell、scala)并喜欢这个概念。我正在尝试将这些功能原则融入我的日常工作中。

这里是一个例子

public class Functional
{

  private final Object o1;
  private final Object o2;

  public Functional(Object o1, Object o2)
  {
    this.o1 = o1;
    this.o2 = o2;
  }

  /*
   * method has side effects 
   */
  private void method()
  {
    //    o1.someChange();
    //    ...
    //    o2.someChange();
  }

  /*
   * method has no side effects - it only uses its parameters
   */
  private static void method(Object o1, Object o2)
  {
    //    o1.someChange();
    //    ...
    //    o2.someChange();
  }

  public void work()
  {
    method(o1, o2);
  }

  public static void main(String[] args)
  {
    Functional f = new Functional(new Object(), new Object());
    f.work();
  }
}

我发现static 方法更易于维护,对于没有编写代码的人来说也是如此,因为他们只需要查看方法参数 - 这在大类中可能是一个优势。另一个小的优势是性能,因为编译后static 方法会被invokestatic 调用,这会稍微快一些。

public 方法仍然保持静态,因为我不想放弃 OOP/封装。我只是在谈论 private static 方法。


问题

那么你觉得这个方法怎么样?特别是。我将所有私有方法设为静态的新习惯有哪些负面影响 - 在合理范围内,只要我不需要超过 3、4 个参数?

【问题讨论】:

  • 这太模糊或太宽泛了。您要求人们将 OOP 风格与函数式编程风格进行比较和对比。您有具体的问题吗?
  • @Raedwald Thx Readwald,那里的一些答案很有用,但我没有新的见解。
  • 个人认为这种做法会导致代码有些难看。您需要访问必须作为参数传递的静态方法中的非静态参数,但是您需要的参数越多,它就会变得越丑陋。也许您应该尝试将实际上需要静态的方法设为静态,也许这对您有用。
  • o1.someChange() 几乎不起作用,因为这表明传递的参数发生了突变。您可以使用不改变对象或其参数的方法轻松地创建 Java 类。这类似于将对象作为第一个参数的函数。如果您返回未更改的对象、新的对象或值,那么它就可以正常工作。

标签: java oop static functional-programming static-methods


【解决方案1】:

恕我直言,您应该在以下情况下使用静态方法

  • 没有参数(罕见)
  • 没有办法扩展感兴趣的类,例如你想为一个字符串添加一个方法。
  • 您想向接口添加方法(Java 8 之前)

否则,静态方法与隐式获取第一个参数的实例方法非常相似。也就是说,您可以简单地将一个转换为另一个。

考虑这些递归方法调用。

class Type {
    static ReturnType staticMethod(Type type, Object arg) {
         return type.method(arg);
    }

    ReturnType method(Object arg) {
         return staticMethod(this, arg);
    }
}

恕我直言,为了清楚起见,您应该尽可能使用实例方法,并将静态方法留给您别无选择的极少数情况。

注意:无论是否使用静态方法,都可以使用函数式编程。要记住的主要原则是 a) 始终将您创建/更改的内容作为返回值返回 b) 不要更改任何参数,包括 this 实例方法。

这使您可以灵活地打破这一点;仅更改 this 而不是其中一个参数(并且仅在必须这样做时)

【讨论】:

  • 我在说关于私有方法,所以在这里提到扩展是没有用的。我的主要观点是,静态方法无法访问非静态实例字段,由于副作用的可能性有限,因此更容易了解该方法的作用。
  • @mike 我同意你儿子不传递你不使用的参数的想法,除非你必须遵守接口。这意味着如果不需要,您不应该传入this,事实上有一个很好的论点是您应该提取不需要的代码部分,因为它们可能会做一些不同的事情。例如假设您有一个实例方法,但是可以将大部分代码提取为静态方法,从清晰的角度来看,这也许是个好主意。
  • 我的目标不是代码提取或重构。我的主要目标是减少内在的混乱并为大班带来秩序。在我的理解中,那些私有静态辅助方法——与非静态方法相反——更加精辟,降低了复杂性,从而帮助人们理解正在发生的事情,因为他们不必考虑整个类。如果一个人通过了this,那么整个点就已经过时了,不是吗。
  • @mike 在我看来,代码提取或重构与构建或编写代码以减少内在混乱并为大类带来秩序之间没有区别。我同意将 this 传递给静态方法是没有意义的,但是将 this 显式或隐式传递给不需要它的方法也不理想。我心中的问题是,当你可以使用静态方法时,你应该在多大程度上鼓励使用静态方法。
  • 在某种程度上,它有助于减少类内的耦合,增加方法的可读性,并帮助您了解方法如何与类内部函数交互。至少这是我的看法,当然这种方法有它的局限性。例如。引入一个带有 5 个以上参数的私有静态辅助方法是没有意义的,因为那样会降低清晰度。
猜你喜欢
  • 2012-02-29
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2014-04-12
  • 2012-03-10
  • 1970-01-01
相关资源
最近更新 更多