当我们改变一个方法的实现时，是不是要重新编译依赖类？

Question

假设我们在 class TaxCalculator 中有以下方法：

public double calculateTax(double income) {
    return income * 0.3;
}

我们在 Main class 中使用此方法，如下所示：

var calculator = new TaxCalculator();
double tax = calculator.calculateTax(100_000);
System.out.println(tax);

如果我将calculateTax方法的实现更改为：

public double calculateTax(double income) {
    return income * 0.4;
}

我是否需要重新编译 TaxCalculator class 和 Main class？

我知道这个问题听起来很傻，但我在一次讲座中听说，如果我们不使用接口，我们在紧耦合代码中所做的每一次更改（就像我上面展示的那样）都会迫使我们重新编译所有依赖的类我们在 class 上进行了更改。

这对我来说听起来很奇怪，因为 Main class 不知道我们所做更改的方法的实现。

在此先感谢您的帮助！

Answer 1

是的，那个讲师完全错了。 更一般地说，这是一个非常过时的概念，曾经是一个有点普遍的说法，许多讲师仍然支持它：

想法是，如果你有一个 class，你会创建一个串联接口，其中包含该 class 中的每个（公共）方法； 考虑到class已经占据了概念的名字，接口不能起个好名字，所以加了一个I前缀。 您有一个class Student和一个匹配的interface IStudent 。

不要那样做。 这是一大堆打字，即使你使用工具自动生成它，每次你改变一个，你就被迫改变另一个，而且没有任何意义。

在Student class 的用户和Student class 代码本身之间获得“更紧密的耦合”与让该用户改用IStudent之间存在着奇特且几乎不相关的方式。 听起来您或者更可能是讲师感到困惑，并认为这种紧密耦合意味着Student.java中的任何更改都需要重新编译。

此外，如果这些例子来自讲座，天哪。 double绝对不能用于任何财务方面。 这应该很可能是一个int或long ，代表美分（或任何传递有关货币的“原子 m.netary 单位”；便士代表英镑，satoshis 代表比特币，yen 代表日元，等等）。 在极少数情况下， BigDecimal 。 无论如何，永远不会是double或float 。

如果出现以下情况，您需要重新编译 B，其中 B 使用 A 的某些内容：

• 您更改 B 直接使用的 A 中常量的值，该常量是“CTC”（编译时间常量）。 只有基元和字符串可以是 CTC，如果字段是static final ，它们是 CTC，并且立即初始化（相对于在单独的static {}块中初始化），并且其表达式本身是 CTC，这意味着它由文字组成以及 CTC 之间可能的简单操作，例如static final int a = 5; static final int b = a + 10; static final int a = 5; static final int b = a + 10; , b也是 CTC。 相反，例如static final long c = System.currentTimeMillis(); 不是编译时间常数，因为System.currentTimeMillis()不是，原因很明显。

• 您更改 B 使用的 A 中任何元素的签名。 即使调用者（此处为 B.java）也可以零更改重新编译。 例如，您在A.java中有： void foo(String param)并且您更改了void foo(Object param) 。 即使foo("hello")是对任一方法的有效调用，您仍然需要在此处重新编译。 相关元素是方法的名称、参数的类型（不是名称）和返回类型。 更改抛出的异常是可以的。 删除 A 中 B 使用的内容自然也是需要重新编译的内容。

基本上就是这样。 接口的插入并没有有意义地改变这个列表——如果那个常量在接口中，同样的原则适用（如果你改变它，你必须重新编译这个常量的用户），如果你改变签名，你会还必须在界面中更改它们，我们又回到了起点。

添加接口确实有一些通常不相关的好处。

• 需要注意的是，任何此类尝试都必须始终回答一个相当尖锐的问题：但是调用者如何创建实例？ 如果讲师使用IStudent student = new Student(); 他们搞砸了，使用界面的一些几乎不相关的好处消失了。

• 如果有有意义的不同实现可用（快速经验法则：如果你能为所有相关类型提出好消息，就是这种情况），使用接口是“正确的”，但这些都不适用。 例如， java.util.List是接口， java.util.LinkedList和java.util.ArrayList是同一想法的有意义的不同实现。

• 专门为测试目的实现接口稍微容易一些。 然而，模拟和扩展 class 也是这个问题的通用解决方案，通常也能正常工作，更一般地说，制作特定于测试的 impl 需要更多的注意，而不仅仅是死记硬背地应用“制作镜像接口”原则。

• 您可以获得额外级别的访问权限 - 您可以在 class 中拥有public内容，但这些内容不会在界面中进行镜像，因此无法通过界面“访问”。 当它们不是真正用于外部消费时，有一个很好的理由将它们public ：当你有一个多包系统时。 Java 的模块系统也承认这一点，并且（通过“导出包”概念）还有效地引入了另一个访问级别（非导出 package 中的public事物无法从其他模块访问，它不像public事物那样公开在导出包中）。 这是过时的，即使在多包库中也有解决它的方法，而且它实际上并没有停止太多 - 你不能强制调用者“编码到接口” ¹

1. 好吧，你可以，但是那些有点笨拙，而且那些也会停止同一个项目中的另一个 package，这就是重点。 您可以使用 hack 来解决这个问题，但如果您愿意使用这些 hack，您可以只public这些内容，但实际上并不意味着非公开的外部消费并使用相同的 hackery。