假设我有一个被设计为实例化的类。我在类中有几个私有的“helper”方法，它们不需要访问任何类成员，只对它们的参数进行操作，并返回一个结果。
public class Example {
private Something member;
public double compute() {
double total = 0;
total += computeOne(member);
total += computeMore(member);
return total;
}
private double computeOne(Something arg) { ... }
private double computeMore(Something arg) {... }
}
是否有特别的理由指定computeOne和computeMore作为静态方法-或者有特别的理由不这样做?
当然，让它们保持非静态状态是最简单的，尽管它们当然可以是静态的，而不会引起任何问题。
当前回答
跑题:我会把辅助方法放在一个独立的实用程序/辅助类中，其中只有静态方法。
在使用点(阅读为“相同的类”)拥有帮助方法的麻烦在于，某些人可能会选择将他们自己不相关的帮助方法发布在相同的位置
其他回答
根据我的经验，我认为这种私有方法往往是相当通用和可重用的。
我认为要做的第一件事是问这个方法在当前类上下文之外是否有用。如果是这样，我将完全按照Everyone的建议，将这个方法作为静态提取到一些utils类，希望在实现新方法之前进行检查，做完全相同的事情。
这种通用的私有方法是项目中很大一部分代码重复的来源，因为每个开发人员都在需要使用它们的地方独立地重新发明它们。因此，这种方法的集中化是一条可行之路。
就像很多人说的那样，让它成为静态! 以下是我遵循的经验法则:如果你认为方法只是一个数学函数，即它是无状态的，不涉及任何实例变量(=> no blue color vars [in eclipse]在方法中)，方法的结果将是相同的'n'次调用(当然，具有相同的参数)，然后将该方法标记为STATIC。
如果你认为这个方法对其他类有用，那么把它移动到Util类中，否则，把这个方法作为私有的放在同一个类中。(尽量减少可达性)
使用静态方法的一个问题是，它会使对象在单元测试中更难使用。Mockito不能为静态方法创建模拟，也不能创建该方法的子类实现。
class Whatever {
public static varType myVar = initializeClassVariable();
private static varType initializeClassVariable() {
//initialization code goes here
}
}
私有静态方法的优点是，如果稍后需要重新初始化类变量，可以重用它们。
在这种情况下，我倾向于让computeOne和computeMore成为静态方法。原因是:封装。访问类实现的代码越少越好。
在您给出的示例中，您指出computeone和computeMore不应该访问类的内部，那么为什么要给类的维护者干涉内部的机会呢?
