最好有2种方法具有明确的含义，或者只有1种双重用途方法？

为了简化界面，最好没有这种getBalance()方法吗？传递0给charge(float c);将产生相同的结果：

public class Client {
    private float bal;
    float getBalance() { return bal; }
    float charge(float c) {
        bal -= c;
        return bal;
    }
}

也许在做个记录javadoc？或者，仅将其留给班级用户以弄清楚如何获得余额？

您似乎建议接口的复杂性是通过接口具有的元素数量（在这种情况下为方法）来衡量的。许多人会争辩说，必须记住该charge方法可用于返回a的余额，这Client比具有该getBalance方法的额外元素要复杂得多。使事情更明确的过程要简单得多，尤其是在界面不增加歧义的情况下，也是如此。

此外，呼叫charge(0)违反了最小惊讶原则，也称为每分钟WTF指标（摘自“清洁代码”，如下图），这使得团队的新成员（或当前成员，在离开代码一段时间后）很难直到他们了解该电话实际上是用来获取余额的。想想其他读者会如何反应：

另外，该charge方法的签名违反了做一件事情和命令查询分离的准则，因为它导致对象更改其状态，同时还返回一个新值。

总而言之，我认为这种情况下最简单的接口是：

public class Client {
  private float bal;
  float getBalance() { return bal; }
  void charge(float c) { bal -= c; }
}

IMO，更换getBalance()用charge(0)在您的应用程序不简化。是的，它的行数减少了，但是却混淆了charge()方法的含义，当您或其他人需要重新访问此代码时，这有可能引起麻烦。

尽管它们可能得出相同的结果，但获得帐户余额与收取零费用并不相同，因此最好将您的疑虑分开。例如，如果您需要修改charge()以在有帐户交易时记录日志，那么您现在就遇到了问题，并且无论如何都需要分离功能。

重要的是要记住，您的代码应该是自我记录的。当我打电话时charge(x)，我希望x被收费。有关余额的信息是次要的。而且，我charge()调用它时可能不知道如何实现，而且明天肯定不会实现。例如，考虑此潜在的将来更新charge()：

float charge(float c) {
    lockDownUserAccountUntilChargeClears();
    bal -= c;
    Unlock();
    return bal;
}

突然间使用它charge()来获得平衡看起来并不好。

使用charge(0);获取余额是一个坏主意：有一天，某人可能会在其中添加一些代码来记录所产生的费用，而没有意识到该功能的其他用途，然后每当有人获得余额时，就会将其记录为费用。（有一些解决方法，例如一条条件语句，内容如下：

if (c > 0) {
    // make and log charge
}
return bal;

但是这些依赖于程序员知道如何实现，如果不是很明显他们是必须的，他就不会这样做。

简而言之：不要依赖您的用户或程序员后继者意识到这charge(0);是获得平衡的正确方法，因为除非有保证确保他们不会错过的文档，否则坦率地说，这似乎是获得平衡的最可怕的方法可能。

我知道有很多答案，但是另一个反对的理由charge(0)是，简单的错字charge(9)会导致您的客户余额在每次要获得余额时都会减少。如果您具有良好的单元测试，则可以减轻这种风险，但是如果您在每次致电时都不勤奋，则charge可能会遇到这种麻烦。

我想提到一个特殊的情况，那就是减少数量，更多用途的方法是有意义的：如果存在很多多态性，即该接口的许多实现；特别是如果这些实现是在单独开发的代码中无法同步更新的（该接口由库定义）。

在那种情况下，简化编写每个实现的工作比清楚地使用它更有价值，因为前者避免了违反合同的错误（这两种方法彼此不一致），而后者仅会损害可读性，这可以通过辅助功能或超类方法限定中回收getBalance在以下方面charge。

（这是一种设计模式，我不记得它的具体名称：用最小的实现者友好的接口定义一个复杂的调用者友好的接口。在Classic Mac OS中，用于绘图操作的最小接口称为“瓶颈”。但这似乎不是一个受欢迎的术语。）

如果不是这种情况（几乎没有实现或只有一个实现），则为了清楚起见而将方法分开，并允许将与非零费用相关的行为简单地添加到charge()中就有意义。