如果它们的类没有成员变量,那么所有方法都应该是静态的

我和我合作过的人发生过争吵,这真的让我烦恼.如果你有一个只有calculateRiskor或和方法calculatePrice的类,那么这个类是不可变的并且没有成员变量,那么这些方法应该是静态的,这样就不必每次都创建一个类的实例.我使用以下示例:

public class CalcService {
  public int calcPrice(Trade trade, Date date) {
    ...
  }
  public double calcRisk(Trade trace, Date date) {
    ...
  }
}

这些方法应该是static吗？

1> sharptooth..：

---

您描述的类只是一组仅对输入进行操作的函数.将这些函数作为类的静态方法是完全合理的.这样做会逻辑地对它们进行分组并消除可能的名称冲突 该类实际上充当命名空间,仅此而已.

---

如果业务逻辑是这些方法很复杂,那么如果你想进行单元测试,你就永远无法模拟它.如果CalcService中存在问题,套件中的其他测试可能会失败.

2> Eric Petroel..：

---

我会说是的,但在这种情况下也可以将这些方法放在Trade对象上.

3> Jack Ryan..：

---

出于可测试性的原因,最近人们普遍反对静态类.

这是因为静态类无法实现接口,因此如果需要,不能轻易替换测试类.我认为像这样处理价格的案例就是一个很好的例子.将来可能有多种计算价格的方法,并且能够在需要时将这些计算器替换为彼此是很好的.

它现在可能没用,但我发现不使用静态类比使用静态类更有优势.

---

但这种情况不正是静态类存在的原因吗？

4> Brian Agnew..：

---

我会避免让这些静止.虽然目前可能有意义,但您可能在将来想要添加一些行为.例如,此时您将拥有默认计算引擎(策略):

CalcService cs = new CalcService();
cs.calcPrice(trade, date);

稍后你可能想要添加一个新的计算引擎:

CalcService cs = new CalcService(new WackyCalculationStrategy());
cs.calcPrice(trade, date);

如果你使这个类可以实例化,那么你可以创建不同的实例并传递它们,动态实例化等.你可以给它们长时间运行的行为(例如,有多少涉及交易X的计算已经完成了这个对象？等等)

5> Julien Chast..：

---

这是一个艰难的电话.记住Josh Bloch关于API的内容:

像钻石一样的API永远存在.你有一次机会把它弄好,所以尽你所能.

(这可能不是一个公共API,但如果你有同事要使用这个代码,它实际上是一个API.)如果你声明这些方法是静态的,你约束他们未来的演变,并在类中合并状态将是困难或不可能.您将不得不使用这些静态方法签名.如果您因为需要状态而决定让它们成为非静态的,那么您将打破客户端代码.我会说,如果有疑问,不要让它们变得静止.也就是说,静态实用程序类有一个包含一堆函数的地方(例如,计算一个圆的面积.)您的类可能属于该类.